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ment of messages, and conferencing modes. The system can 
be implemented in any Internet-based computer network (160), 
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nents include a server application (100), a client application (ISO) 
and a data repository (108) maintained by the server (100). The 
server records in the data repository pertinent information regard- 
ing communications between and requests issued by users (158), 
and handles the communications cooperatively with the client 
(150) in accordance with the system mode being exercised (e.g., 
talk, conferencing, whisper, mail, messaging, open display, pri- 
vate bulletin boards, etc.). 
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COMMUNICATION BOARD SYSTEM AND METHOD 
FOR USE IN COMPUTER NETWORKS 

The present invention relates generally to electronic communication systems for use 
in computer networks and, particularly, to bulletin boards, instant messaging 
systems, electronic mail and chat rooms. 



BACKGROUND OF THE INVENTION 



— — An electronic communication system for use in enterprise and other collaborative 
environments would Ideally include a suite of capabilities that facilitate decision 

10 making and communication by two or more individuals. Such capabilities could 
include: 

• enabling users to view the history of multiple conversations with 
multiple parties (referred to hereinafter as "conversation history"); 

• enabling users to view messages as soon as they are available 

15 without requiring the users to log onto a public bulletin board system 

(BBS) (referred to hereinafter as "instant access"); 

• enabling users to view the content of messages without requiring that 
the messages first be selected (referred to hereinafter as "open 
display"); 

20 • enabling users to conduct their conversations in privacy so that each 

user is the only person who can view the history and content of their 
resp ctive multiple conversations (r ferred to hereinafter as "privat 
conversations'); 
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nabling users to undeniably agree to proposals made in the course of 
a conv rsation in such a way that th conversation is concluded 



(referred to hereinafter as "agreement" ); and 
• enabling users to participate in moderated conferences or informal 
5 chats, as well as in conversations (referred to hereinafter as 

"integrated modes"). 

Prior art electronic systems, which include electronic mail (e-mail), bulletin board 
systems (BBS), instant messaging and chat rooms, offer some but not all of these 
10 capabilities and, as a result, are less then ideally suited to enterprise 

communications. The capabilities of these various communication systems are 
presented in Table 1. 



TABLE 1 



15 


System 


Conversation 


Instant 


Open 


Private 


Agreet 


Integrated 






History 


Access 


Display 


Conversations 




Modes 




E-mail 


No 


Yes 


No 


Yes 


No 


No 




BBS 


Yes 


No 


No 


No 


No 


No 




Instant 


No 


Yes 


Yes 


Yes 


No 


No 




Messaging 














20 


Chat 


No 


Yes 


Yes 


No 


No 


No 



Referring to Table 1, e-mail systems offer instant access to messages, but the 
messages must be selected and opened by the recipient (typically with a mouse 

25 click) to be viewed. E-mail messages are private as they are directed to specific 
recipients (one or many). No viewable history is available for E-mail messages 
except for the most rudimentary kind wherein a message being replied to can be 
copied into the body of the response. E-mail has only one mode and includes no 
feature whereby an e-mail user can issue a formal agreement to a proposal 

30 contained in a message, other than so stating in a reply message; e.g., "I agree to 
your proposal of 12/1 0/97 on the subject of contract terms." 



Wo '99/48011 " PCT/US99/06074 

-3" 

Like e-mail systems, bulletin board systems (BBS) do not provide open display, 
agreement, r int grated mode capabilities. Unlike E-mail systems, BBS display 
messages in a threaded format wherein a topic is listed first and all messages 
germane to that topic are listed below the topic with different levels of indentation 
5 indicating historical and logical relationships between the related messages. For 
example, a BBS might display a topic and two messages on the topic, the first 
having an associated comment, as follows: 
Topic: Discussion of X 
Message 1 

-tO Comment on Message 1 

Message 2 

Because BBS do not provide open display, a user must select a message or 
comment to read that message or comment. BBS are centralized systems, meaning 
that a user must actually log in to the BBS to view topics and messages. As a 
15 result, messages are not immediately accessible (i.e., to read messages on a topic 
of interest a user must first access the BBS). Also, BBS are anything but private; 
typically, the same bulletin board is available to all users, meaning that all 
messages are accessible to all users. 

20 Instant messaging systems allow users to communicate privately in real time over a 
network connection. An example of such a system is America On Line's "Instant 
Messages" feature, which allows an AOL member who is online to communicate with 
another member who is also online at the same time. Messages are openly 
displayed (i.e., without needing to be selected first). Thus, instant messaging 

25 systems provide private conversations, immediate access and open display 
capabilities. However, instant messaging systems do not support conversation 
history, agreement or integrated modes. Moreover, instant messaging systems are 
for one-on-one communication only. 

30 Chat systems allow a group of users to enter a chat room and then engage in a 
group conv rsation. The group conversation can b moderat d or un-mod rat d. 
Like instant messaging, chat systems are for informal communications and do not 
provide conversation history, agr ement or integrated modes. Also like instant 
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messaging, chat syst ms openly display all messages. Howev r, chat m ssages 
are not immediately accessible as a user needs to nter a chat room before they 
can view messages. Also, chat rooms are not private as anyone in the chat room 
can read all chat messages typed by users in that room. 

5 

Consequently, there is a need for an enterprise communication system that provides 
features and/or combinations of features not present in prior art electronic 
communication systems. 

10 

SUMMARY OF- THE INVENTION 

In summary, the present invention is a electronic communication system that 
provides features and/or combinations of features not present in prior art electronic 
15 communication systems. In particular, the present invention is a communication 
board system with multiple modes in which the communication board system can be 
variously configured as: 

• a threaded instant message system (conversation history plus instant 
access capabilities); 

20 • an open display bulletin board system (conversation history plus open 

display capabilities); 

• private message boards (conversation history plus private 
conversations capabilities); 

• a system allowing message locking (conversation history plus 
25 agreement capabilities); and 

• a threaded mail system. 

The preferred embodiment of the system is implemented as a client server system 
including a server application, a client application and a data repository resident on 
30 the server. In the preferred embodiment a sender requests communication services 
using his client application, which relays the request to th serv r program. The 
server program updates the data repository to r fleet the request and th n issu s an 
appropriate message to the client application of one or more recipients, depending 
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onlh requ sted communication services. Any response by a recipi ntis 
cooperatively handled by the client and server applications in the same manner as 
the initial request. All communications activities are moderated by the server 
application and recorded in the data repository. 

5 

The data repository is preferably structured as a set of relational database tables, 
including a users table and a messages table. The users table lists characteristics 
-of all system users, including unique ID, name and preferences. The messages 
table lists characteristics of each message issued by users, including a unique 
1 0 -message ID, threading information (parent and child message IDs) sender and 
recipient name, subject, status of the message (unread, read, responded, 
acknowledged, etc. ), type of message (thread, invitation, confirmation, log), 
miscellaneous flags, and the name of the file where the message text is stored on 
the server. 

15 

In the preferred embodiment a sender sends a message to a recipient by filling in a 

— ~sendmessage template-displayed by the client application, which relays the 
completed message information to the server application. Upon receiving the 
message information the server application stores the pertinent information (sender, 

20 recipient, subject) in the message table, updates message status fields and 

threading information for the same message table record, stores the message text in 
a file, and issues the client application of the intended recipient a pending-message 
alert Preferably, the server application sends the pending-message alert only when 
the users table indicates that the recipient is online, although this is not a 

25 requirement of the present invention. The client application gives the recipient an 
opportunity to do nothing, cancel the alert, or accept the message. If the user does 
nothing, the server resends the alert at some prescribed interval. If the user cancels 
the alert, the server will not resend the alert and places the message on hold. If the 
user accepts the message, the server sends the relevant message information to 

30 the client application to be accessed by the recipient. 

When the preferred embodiment is configur dasaprivat m ssag board system, 
each user interacts with the communication system via a private bulletin board in 
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which the client application instantly displays the history and content of all 
messages associated with conversations in which the respectiv user is a party. In 
this configuration the present invention supports multiple instances of instant 
messaging, meaning that it provides private bulletin boards for multiple users and is 

5 able to allow each of the multiple users to exchange instant messages with one or 
more other users. In this case the relevant message information returned by the 
server application to the intended recipient includes threading information, which 
enables the client application to display the message's history along with that of 
other messages. Preferably, the client application displays the messages in open 

10 format; however, the client application could also display the messages in the 
conventional format. 

Once a recipient has accepted a message, he can reply to or acknowledge the 
message. The message reply feature is implemented cooperatively by the client 

15 and server applications in the same manner as the message send feature. 
Message acknowledge is a feature of the present invention wherein a 

^conversation's thread is closed, indicating that the conversation has been 

concluded, typically with some agreement For example, a user can indicate final 
acceptance of sales terms set out in the last of several threaded messages by 

20 acknowledging that message. The client application relays message acknowledge 
information to the server application, which updates the data repository by setting 
the message status to acked and closing the corresponding thread. Thus, the 
present invention allows the entire history of a negotiation to be preserved along 
with its final agreement. 

25 

The other system configurations can be implemented using the components of the 
preferred embodiment with minimal changes from the above description. 

In the preferred embodiment, the client application is based on a web browser and 
30 the server application includes communication board software that performs all high 
lev I and data repository operations and web server softwar that decodes and 
encodes communications from and to the client web browser. Pref rably, all 
communication b ard contents displayed to us rsar formatted as ACTIVE 
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SERVER PAGES whose fields can be dynamically filled in by the user via the client 
web browser or by th server's communication board softwar using information 
from other users and/or the data repository. ~~~~~ 

5 Another feature provided by the preferred embodiment is message hyperlinking, 
which allows a user to form a response to any message shown on their private 
bulletin board by simply selecting a hypertext link identifying the message sender. 
In response to the selection of a hyperlink the client application generates the 
appropriate response screen with some of the fields (e.g., sender, recipient, subject) 

10 fiiled-in. 



The preferred embodiment supports multiple integrated modes, including a threaded 
communications (message) mode, already described, talk mode, conference mode, 
whisper mode and mail mode. The present invention allows users to transition 
1 5 smoothly between the modes. 

— Conference-mode^allows-users to participate in moderated or unmoderated 

conferences that are scheduled or unscheduled. Information regarding conference 
participants and scheduled time and moderator, if applicable, are stored by the 

20 server application in a conferences table within the data repository. When a user is 
to participate in a scheduled conference he is notified of the virtual conference room 
and time of the conference by the server application. The server application also 
creates the virtual conference room at the appropriate time, registers participants, 
and stores a log of the conference in the data repository. In a preferred 

25 embodiment conference mode conversations are unthreaded. Whisper mode is 
available to participants in a conference who wish to paricipate in a private, side 
conversation. 

Talk mode allows users to participate in informal, unlogged conversations. In a 
30 preferred embodiment talk mode conversations are unthreaded. 

Mail mode allows a user to send e-mail over the Internet with two levels of 
threading. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Additional objects and features of the invention will be more readily apparent from 
the following detailed description and appended claims when taken in conjunction 
with the drawings, in which: 

FIG. 1 is a block diagram of a preferred embodiment of the-present invention; 

FIG. 2 is a block diagram of the database tables 140, 142. .144, 146, 148 from FIG. 
1; 

FIG. 3A is a data flow diagram illustrating the relationships between a client 
application 166 and web browser 168, the web server 1 16, the server application 
114 and the PMB databases 108 when a user is sending a message; 

-ElG^3B-is^a-block-diagram-of,new records_allocatedjn Jhe„various tables by the 
server application 114 while processing an exemplary send request; 

FIG. 4A is a data flow diagram illustrating steps performed by the web browser 168- 
1 of a message sender, the server application 1 14 and the web browser 168-2 of a 
message recipient for a message send procedure; 

FIG. 4B is an image of a private communication board screen on which instant 
messages owned by one user are presented in a threaded, open format; 

FIG. 4C is an image of a second private communication board screen on which 
instant messages owned by a second user are presented in a threaded, open 
format; 

FIG. 4D is an image of a private message review board that presents for one user 
all of the user's messages having a common subject; 
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FIG. 5A is a data flow diagram illustrating steps performed by a web brows r 168-1 
of a message replier, the server application 114, and a web browser 168-2 of a 
messageTeplyTecipjentfo^ 

5 FIG. 5B is a block diagram of new records allocated in the various tables by the 
server application 114 while processing an exemplary reply request; 

FIG. 6 is a data flow diagram illustrating steps performed by the web browser 168-1 
of a message acknowledger and the server application 1 14 for a message 
10 acknowledge procedure; 

FIG. 7A is a flow chart illustrating steps by which the server application 114 
schedules and implements a conference; 

15 FIG. 7B depicts an exemplary communications board for a particular user illustrating 
conference notifications and announcements; 



FIG. 7C depicts a conference screen displayed by client Web browsers 168 for all 
clients participating in a conference; 

20 

FIG. 8A is depicts a talk entry screen displayed by client Web browsers enabling a 
user to transition to talk mode; 

FIG. 8B is depicts a talk session screen displayed by client Web browsers during a 
25 talk session; and 

FIG. 9 depicts a mail screen displayed by client Web browsers that supports 
threaded Internet e-mail. 



30 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 

" Referring to FIG. 1 , there is shown a block diagram of a preferred embodiment of 

the present invention. This embodiment includes a server 100 with a server memory 
5 106, processor 102, hard disk 136 and database 108. The server memory 106 could 
be any combination of a RAM or cache memory and includes an operating system 
110, application programs 1 12 and data 118. In accordance with well known 
principles, the processor 102 executes the applications 1 12 tn the memory 106 
und$r control of the operating system 110. 

10 

The applications 112 include a personal message board (PMB) server application 
embodying many of the teachings of the present invention and a web server 116, 
which could be any program configured to serve web content over a network. The 
applications 112 also include communications application 117, which are programs 

1 5 that employ features of the server application 1 1 4. The data 1 1 8 include ACTIVE 
SERVER PAGES (ASP) 120 that describe the contents of web pages through which 
clients 150 exercise the modes of the present invention including messaging, 
conferencing (incorporating a whisper mode for conference participants), talk, and 
mail. The ASP 120 therefore includes a messages page 122, a conference page 

20 124, a whisper page 126, a chat page 128, a mail page 130 and other pages 132 
needed for miscellaneous client-server communications. 

Message mode allows a user to interact with a private bulletin board in which his 
messages (Le., any message involving the user as sender or recipient) are instantly 

25 available and displayed with full threading information. Message mode supports an 
acknowledge (Ack) reply which, when sent by a user in response to a particular 
message, closes the thread comprising the particular message and records the 
users acknowledgment that they read/accepted the message. Because each 
bulletin board is private, no user other than the authorized user can view its 

30 contents. 

Conference mode allows users to participate in moderated or unmoderated 
conf rences that are scheduled or unscheduled. Information regarding conference 
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participants and sch duled time and moderator, if applicabl , are stored by th 
server application in a conferences table within the data repository.. Wh n a user is 
to participate in a scheduled conference he is notified of the virtual conference room 
and time of the conference by the server application. The server application also 
creates the virtual conference room at the appropriate time, registers participants, 
and stores a log of the conference in the data repository. In a preferred 
embodiment conference mode conversations are unthreaded. Users involved in a 
conference can enter whisper mode, in which they can converse privately, without 
logging. 

Talk mode allows users to participate in informal, untagged conversations. In a 
preferred embodiment talk mode conversations are unthreaded. Mail mode allows 
a user to send threaded e-mail over the Internet. Each of these modes is integrated 
so that users can transition from one to the other. 



In the preferred embodiment, the database 108 is a relational database system 
including tables organized to store information written and retrieved by the server 
application 1 14 in the course of its operation. The database tables include a users 
table 140, messages table 142, conference table 144, threads table 146 and a 

20 thread participants table 148. The tables 140-148 respectively store information on: 
system users (140), messages exchanged between users (142), conferences of 
users (144), mapping of messages to threads (146), and mapping of thread 
participants (users) to threads (148). These tables are described in depth in 
reference to FIG. 2. The hard disk 104 includes message files 136, which store the 

25 text of messages referred to by the messages table. 

The embodiment shown in FIG. 1 also includes one or more clients 150, each of 
which is used by one or more users. The single client 150 shown is representative 
of the one or more possible clients. In the preferred embodiment, clients 1 50 are 
30 coupled to the server 102 via an intranet 160; however, the principles of the present 
invention ar qually applicable to any type of network, such as the Internet, an 
extranet or combinations thereof. The client 150 and th s rv MOO xchang 
information over the network 160 using standard network protocols, such as TCP/IP 
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andHTTP. In particular, th serv r application 114 makes availabl to users 
communication board services (encompassing private message boards, chat, talk, 
conferencing and mail) by transmitting to the clients 150 via the web server software 
1 16 manifestations of the ACTIVE SERVER PAGES 120 and other web pages. 
5 These manifestations, when displayed by the clients 150, enable the users to view 
communications board information and messages from other users, and to issue 
requests and queries to the PMB application 1 14 via the web server software 116. 

The client 150 includes a memory 156, processor 152, hard disk 154 and user 
10 interface elements 158, such as a display, keyboard and selection device. The 
memory 156 could be any combination of a RAM or cache memory and includes an 
operating system 162, application programs 164 and data 170. In accordance with 
well known principles, the processor 152 executes the applications 164 in the 
memory 156 under control of the operating system 162. 

15 

The applications 164 include a personal message board (PMB) client application 
-^=t66 and=a^web ; t)rowseH68f = The web browser 168 receivesrtransmits and 

presents manifestations from the ASP 120 and other pages transmitted over the web 
by the server application 1 14 via the web server 116. The client application 166 

20 provides additional processing capabilities not present in the web browser 168 to 
assist users in interacting with the communication board features. These additional 
processing capabilities can include: responding to alerts from the PMB application 
114 when the user is not available, locally logging user sessions, maintaining a local 
address book for the user and issuing standard queries or requests to the server 

25 application 114. Note that simple implementations of the present invention can 
eliminate the PWB server application 166; in such an implementation all user 
interaction would be provided by the web browser 168. Because communications 
between the server 100 and clients 150 adhere to web standards and the key 
components of the present invention (i.e., the PMB server application 114 and PMB 

30 client applications 166, described below) are compatible with standard web software 
(i.e., the web serv r 1 16 and browser 168), the present invention can b 
implemented in any web based client server environm nt. Mor over, with slight 
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modification, the s rver and client applications 114, 166 could be made compatible 
with any standard client/server communications packages (e.g., Novell, etc.). 

The data include manifestations 172 of the ACTIVE SERVER PAGES (ASP) 120 
5 downloaded by the web browser 168 in response to events or user requests. These 
manifestations (not shown in detail) enable the user to employ and interact with the 
features of the PMB server application, including the following modes: messaging, 
bulletin board, conferencing, chat, and mail. The manifestations are presented by 
the web browser 166 to users as visuals 162 and/or sounds 164 using the user 
10 interface elements 158. 

The present invention is not limited to the described embodiment. In fact, the 
teachings of the present invention are applicable to any combination of current 
and/or future technology similar to that described herein. For just one example, the 
15 database 108 can be implemented using an object-oriented DBMS, flat text files 

stored on a hard disk 104, or other DBMS or non-DBMS solutions. Having generally 
-""^escnbedW^^ 

108 are now described in reference to FIG. 2. 

Referring to FIG, 2, there is shown a block diagram of the database tables 140, 142, 
144, 146, 148 from FIG. 1. The users table 140 holds information pertaining to 
authorized users of the communication board (i.e., the server application 114). The 
users table 140 fields include: 

Id Unique number automatically assigned to each user, 

[primary key] 

Name Assigned name for user's account. Used to logon with. 

DisplayName User's name as it appears in the heading of their Comm 
Board. 

Password To restrict account access by unauthorized users. 

SortPrefs User's sorting preferences - a 3 character code: 

c=chronological, r=r v rse chronological, s=subj ct, 
e-sender 



20 



25 



30 
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ExpiryPref 



Number of days after which a messag expires and is 
deleted. 

Flag is set to true when user has unread mail. 

Flag is set to true when user has been invited to join a 

conference. 

Flag is true if user does not want alerts for new 
messages, etc to interrupt their session. 



HasNewMall 
Haslnvitation 

HoldAlerts 



The messages table 142 holds information pertaining to individual messages. Each 
10 participant in a message owns an individual message recoreh- This allows for 
personalized manipulation of a given message. The messages table 142 fields 
include: 

Msgld Unique number assigned automatically to each message, 

[primary key] 

MsgFileName Name of file that contains message body text. 
ThreadLevel Number 1-6 designating message's level in thread. 



15 



20 



25 



30 



Threadld 
Parentld 



Id of corresponding Threads~table record. 



Id of message that is above this message in the message 
thread. Value is zero if message is at top of thread. 
Id of message that is below this message in the message 
thread. Value is zero if message is at the bottom of 
thread. 

Year, month, day, hour, minute and second when 
message was sent. 

Name of user that owns this message record (sender or 
recipient). 

User Id of message sender. Corresponds to id in Users 
table. 

User name of message sender. 
SenderNameASCI SenderName sort number. 
Recipient User name of message r cipient. 

RecipientList Complete comma delimit d list of recipients. 
CcList Complete comma delimit d list of carbon copy recipients. 



Childld 

MsgTimeStamp 
MsgRecOwner 
Senderld 
SenderName 
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IsCarb nCopy 



Flag is true if recipient is in ccList rather than 
recipientList. 



Message subject or conference name. 
Subject sort number. 

Date message was acknowledged rather than responded 
to. 

Flag is true if message has been responded to. 
Message status contains one of these values: unread, 
read, repliedTo, acked, stored, deleted, abandoned. 
Type of message contains one of these values: thread, 
announcement, invitation, confirmation or log. A thread 
type is a message that appears as part of a thread. An 
announcement is a simple message sent to all users by 
default. Announcements do not allow for a reply. An 
invitation is automatically sent to users that are invited to 
a conference. A confirmation is automatically generated 
"when a user responds"t5~ahlfwitati6n^ 
complete record of a given conference. 
Date message is to be expired (automatically deleted). 
Flag is true if message is forwarded. 
Id of thread being forwarded. 



10 



15 



20 



Subject 

SubjectASCI 

AckDate 

IsRespondedTo 
Status 

Type 



ExpiryDate 

IsForward 

ForwardThreadld 



A thread includes a first level message and subsequent replies, which can be added 
to the thread until the thread is closed by one of the thread participants issuing an 
25 explicit acknowledgment to one of the thread's messages. The threads table 

contains one thread record for each message thread that is unique by subject. The 
threads table 146 fields include: 

Threadld Unique number assigned automatically to each thread, 

[primary key] 
30 Subject Thread subject. 

SubjectASCI Sort number for subject. 
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When ver a user participates in a thread - that is, wh nh is as nderorr cipient 
(even if only a CC recipient) - an entry is made by the server application 1 14 in the 
thread participants table 148. This table facilitates the gathering of message 
threads by subject for a given user. For example, the server application 1 14 would 
5 gather such information for a particular user by: 

1 ) issuing a query in the ThreadParticipants table 1 48 to find Threadlds 
of all threads a user with a particular UserlD has participated in; 

2) issuing a query in the Threads table 146 using the ThreadlDs from 
query 1 to identify the subject sort numbers (SubjectASCl) for the 

10 respective threads; and 

3) issuing a query in the Messages table 142 with the SubjectASCl 
values from query 2) to identify all messages with the same subject for 
the user. 

15 The thread participants table 148 fields include: 

Participantld Unique number assigned automatically to each thread. 

[primary key] 

Threadld Thread ID (correlated with thread subject). 

Userld ID of user who is thread participant. 

20 

The conferences table 146 holds basic information about each conference. The 
conferences table 144 fields include: 

Id Unique number assigned automatically to each 

conference, [primary key] 
25 Moderatorld User id of conference moderator. 

Topic Moderator assigned topic for conference. 

Type Type of conference contains one of these values: private, 

public. 

Participants Comma delimited list of users invited to join a private 
30 conference. 

IsSchedul d Flag is true if the confer nc is scheduled for a later date 
asoppos d [to?] immediat ly. 
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When Time of conference if the conference is scheduled for a 

later time. 



Referring to FIG. 3A, there is shown a data flow diagram illustrating the 
5 relationships between a client application 166 and web browser 168, the web server 
116, the server application 114 and the PMB databases 108 when a user is sending 
a message. The progression of operations shown in FIG. 3 is preceded by a SEND 
request issued by a user that is relayed via the user's web browser 168 to the 
sender application 1 14 via the web server 116. The sender application 1 14 in 
10 response returns a manifestation of a SEND page, which the web browser 168 

displays as a SEND page visual 162. The user then completes at least a subset of 
the fields of the SEND page, which include: TO (i.e., one or more recipients), FROM 
(i.e., sender name), SUBJECT (i.e., message subject) and MSG (i.e., message text). 
It is assumed for this example that the message being sent is a level one message 
1 5 that starts a new thread of conversation. 

The progression shown in FIG 3Arbegins when the user sends the message by 
selecting the displayed SEND button on the visual (3.1). in response to the 
selection of the SEND button (3.1) the web browser 168 (possibly with some 

20 intervention of the client application 166) issues an HTTP message transferring the 
SEND data to the web server 116. In accordance with the HTTP (hypertext transfer 
protocol) the browser 168 transmits the SEND data to the web server 1 16 (3.2). The 
message (3.2) includes the URL of the page for which the data is being transmitted 
(i.e., "SendMsg") and the encoded data Upon receiving the message (3.2) the web 

25 server 116 decodes, re-packages, and transmits (3.3) the data to the server 
application 114. 

Upon receiving the message (3.3), the server application 1 14 performs the following 
operations (3.4-3. 1 4): 
30 3.4) Determines from the users table 1 40 the IDs of sender and 

recipient(s). 

3.5) Writes the MsgTxt to the hard disk (3.5) as a message fil 1 36 and 
generates a corresponding file name (MsgFil Name). 
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3.6) Generates a unique ID (MsgID) and sortabl subj ct number 

(SubjectASCI) for the message. 
3J) Allocates in the messages table 142 2N message records 143, N for 

the sender 143s and 1 for each of the N recipients 143ri (where i is an 
5 integer between 1 and N); 

3.8) Updates each message record in accordance with the message data 
(only selected field are shown): 

MsgID « message ID generated by server app. 114; 

MsgFileName = message name generated by server app. 114; 
10 ThreadLevel = 1 (message is at the top of a thread); 

ParentID = 0 (message is at the top ofe thread); 

Childld = 0 (message is also at the bottom of a thread); 

MsgRecOwner = name of a respective one of the participants 

SenderlD = ID of sender; 
15 SenderName = user name of sender; 

Recipient = user name of a respective one of the N recipients; 

Recpienttist = list of N recipients; 

Subject = subject completed by sender, 

SubjectASCI = subject sort number generated by server app. 
20 AckDate = 0 (message not yet responded to); 

Status = unread (message not yet received); 

Type = thread (message is part of a thread); 

3.9) Generates a unique thread ID (ThreadID) for the thread started by the 
message. 

25 3.10) Allocates a single record 147 in the threads table 146; 

3.1 1 ) Updates the thread table record: 

ThreadID = thread ID generated by server app. 114; 
Subject = subject completed by sender; 
SubjectASCI = sort number for subject generated in step; 
30 3.12) Generates a participant ID (ParticipantID) for each participant (1 for 

sender and 1 for ach of the N recipients); 
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3.13) Allocates in the ThreadParticipants Table 148 N+1 records 149, one 
for the s nder 149s end N for each of th N recipients 149ri (where i is 
an integer between 1 and N); 

3. 1 4) Updates each ThreadParticipant record 1 49 as follows: 

ParticipantID = participant ID generated by server app. 1 14 
ThreadID = thread ID generated by server app. 114 
UserlD = message name generated by server app. 114 
ThreadLevel = 1 (message is at the top of a thread); 



10 -Referring to FIG. 3B, there is shown an example of how, as a result of the send 
processing performed by the server application 1 14, multiple records of the 
respective tables are generated and cross-referenced. FIG. 3B assumes a simple 
example where a user with usemame ArnieS has sent a message to two co-workers, 
BobB and SueG. Information for these users is provided in the users table 140, 

15 which shows UserlDs (U007, U019, U027) and DisplayNames (Arnie, Robert, 

SueEllen) for ArnieS, BobB and SueG, respectively. Upon receiving the message 

— ^e^enrer-applicfction-l^^cre^ the 
messages table 142. Two messages (Msgld=M001 , Msgld=M002) list ArnieS as 
MsgRecOwner; one of these has BobB as Recipient and the other has SueG as 

20 Recipient. The other two messages (MsgId=M003, Msgld=M004) are similar, but list 
BobB and SueG as respective MsgRecOwners. Multiple messages are created so 
each participant (sender or recipient) can independently manipulate their own 
messages. For the same message, a single new Threads table 146 record has 
been allocated (Threadld = T001). This single record is associated with all 

25 messages having the same subject (i.e., "The Lee Account") and a corresponding 
unique index (S050). This same ThreadID is associated, for example, with any reply 
by any of the recipients of the original message as well as any subsequent replies 
by the original sender. The server application also allocates 3 thread participant 
records (with Participantlds = P021, 025, 032), one each for ArnieS, BobS and 

30 SueG. These participant records map the participants to their respective userlDs 
(U007, U019, U027) and to the new thread record (Thr adld = T001) associated 
with the subject common to all messages. 
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Referring to FIG. 4A, there is shown a data flow diagram illustrating steps performed 
by th web browser 168-1 of a message s nder, the server application 114 and th 

web1>rowser168^ctf^^ The 

steps illustrated in FIG 4A occur after the user of the client 150-1 has sent a 
5 message (41) designating a user of the client 150-2 as recipient and the server 
application 114 has processed that message as described in reference to FIG. 3A. 
As part of the processing described in reference to FIG. 3A the server application 
114 determines the recipient(s) of the message (4.2). The server 114 then 
determines whether the recipient(s) is/are on the system (4.3). If the recipient is on 

10 the system, the server application 114 sends a message-alert (MsgAlert) to the 
recipient (4.4). The MsgAlert (4.4) notifies the intended recipient that a first level 
message is waiting for him. The recipient application/browser 166-2/168-2 displays 
the alert in an alert window (4.5) that gives the recipient two response alternatives: 
OK or CANCEL (4.6). The recipient selects OK to indicate to the server application 

15 114 that he wishes to receive the message. He selects CANCEL to indicate that he 
does not wish to receive the message and does not want to receive further alerts. 
The recipient.can=also,choose,noUo,respond to the alert at all. This commonly 
occurs when the recipient is away from his computer. 

20 After sending the MsgAlert (4. 1 ) the server application 114 waits (4.7) for the 

recipient's response. If the response is NULL, (meaning that the recipient did not 
respond for some predetermined time interval; e.g., 90 seconds) the server 
application 114 resends the MsgAlert (4.8a). 

25 if the response is OK, the server application sends the Message (4.8b) and updates 
the messages table 142 to show that the message has been posted. This update 
involves changing the status 260 of the messages table records 230 for the sender 
and recipient of the message from "unread" to "read" 230. The server application 
114 also sends at the same time any other messages which were in abeyance at the 

30 server 100 (i.e., messages previously sent but not OKed for delivery by the 

recipient). The status of each of these messages is also updated accordingly by the 
serv r application 114. The recipient application/browser 166-2, 168-2 then 
displays the messages in an open, threaded communication board format that is a 
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key feature of the pr s nt invention. This display format is described below in 
refer nee to FIG. 4B. A unique asp ctofth described sequence of operations is 
that a user is able to view their communication board messages instantly (that is, as 
soon as they issue an OK), without first needing to log on to a centralized bulletin 
5 board system. Another advantage of the present invention is that the messages are 
displayed with full threading, which is not possible with conventional instant 
messaging systems. 

If the response is CANCEL, the server application 114 places the message in 
10 abeyance (i.e., does not send it) and sends another message to the 
application/browser 166-2, 168-2 causing a message indication to be 
displayed/played on the client user interface 158. For example, the message 
indication could be an alert light or a sound indication, among many other 
possibilities. 

15 

Referring to FIG. 4B, there is shown an image of a communication board format 400 
employed^The presehtiiWentiorrto display fdnsTs^ 

status of conversational threads (e.g. f 460, 462, 464, 466) in which that single user 
has participated. This image is displayed as a visual 162 on the user's client 

20 computer by the application/browser 166-2/168-2 based on inputs received from the 
server application 1 14. The communication board 400 displays all messages and 
threads owned by a user regardless of subject These messages are displayed until 
they are deleted by a participant, they expire, some event occurs that triggers their 
automatic deletion, or the system administrator deletes them. In addition to 

25 messages (including forwarded and carbon copy (cc) messages), the 

communication board 400 displays announcements broadcast to multiple users and 
conference notifications. 

The communication board 400 lists for each message information from a 
30 corresponding messages record, including its MsgTimeStamp 242, Recipient 246, 
Send rName245, CcList250, Subj ct 254 and MsgText. In th illustrat d 
embodiment the MsgTimeStamp 242, Recipient 246, SenderName 245 and CcList 
250 are displayed on the first line 402 of a message, which is call dth informati n 
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line. The Subject 254 is displayed on the second line 404 and th MsgT xt 406 is 
displayed on subsequent lines. • 



In a preferred embodiment, the communication board display is private, meaning 
5 that each user can view only their messages (i.e., messages for which a user is 
listed as MsgOwner in the messages table 142). The present invention is able to 
support this private treatment of messages as it allocates for each one-to-one 
communication two message records 230, one owned by the Sender and one by the 
Recipient A unique feature of the present invention is that messages and replies 
10 thereto appear simultaneously on the communication boards of both the sender and 
the recipient. 

The client displays the messages with full threading information. That is, first level 
messages 442 are displayed with no indentation and lower level messages (i.e., 

15 replies 444 and replies to replies 446) are displayed with corresponding levels of 
indentation. The information necessary to maintain message threading is provided 
by the server application 114 from the Parent, Child, ThreadLevel and Threadld 
fields 238, 240, 236, 237 of the messages table 142. In particular, each displayed 
thread comprises a first level message and its children (family of replies). Note that 

20 many threads can have the same subject (e.g., the threads 460 and 464); however, 
each first level message with the same subject is displayed as a distinct thread. 

To assist user recognition of the different message levels and the status of those 
messages (read, unread, etc.), the displayed embodiment employs color and icons 

25 in addition to indentation. In particular, first level messages are preceded by a 
filled-in square 408, second level messages (replies) are preceded by a filled-in 
diamond 410 and third level messages (replies to replies) are preceded by a filled-in 
circle. In the illustrated embodiment the information line of incoming messages is 
underlined with different colors depending on whether the message has been 

30 responded to (shown in purple) or need to be responded to (shown in blue). 
Alternatively, the information line of all incoming messages can be shown in on 
color (e.g., blue) and with underlining only when the incoming m ssage has not yet 
been responded to. Not that these display features (indentation, color, icons) ar 
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not requir d by the present invention but are niceties to assist users in navigating 
th open, threaded communication board 400. 



A novel feature of the present invention is message acknowledge (Ack), which 
5 allows a message recipient to agree to/acknowledge a particular message in such a 
way that their agreement/acknowledgment is unambiguously recorded by the server 
application 114. In the displayed embodiment the present invention displays an Ack 
field 420 alongside the information line 402 of all second and third level messages 
that indicates when and how (explicity or implicitly) a messageMjvas acknowledged. 

10 An Ack field 420 is not displayed next to first level messages-iathe preferred 
embodiment, but this could also be done in alternative embodiments. The 
acknowledge feature is useful in business applications where it can be used to 
memorialize agreement; e.g., to proposals contained in messages. The 
acknowledge feature also serves to inform senders as to whether or not recipients 

1 5 have read their messages. 

When-a~useracknow^ application 

114 displays the date and time of the acknowledgment on both the sender and the 
recipient's communication boards 400. Explicit selection results in the closing of a 

20 thread, meaning that no more replies on that particular thread are possible and that 
subsequent conversations on the same subject would require a new first level 
message. In the displayed embodiment the Ack field of closed threads are 
underlined with a characteristic color (e.g., red) on the communication boards of 
both participants (e.g., see the Ack field 420-1). 

25 

A user can implicitly acknowledge a received message by replying to that message 
(e.g, by sending a third level message). In this case the server application 114 fills 
in the Ack line 420 of the second level message with the date and time the third 
level message was sent When such a reply is sent the server application 114 does 
30 not close the thread as the reply merits its own acknowledgement. As a result, the 
server application 1 1 4 do s not display the Ack field 420 with th characteristic 
color of a closed thread (e.g., see the Ack field 420-2). 
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If the recipient of a second or third message has not repli d or acknowl dged to 
such a message, the Ack field 420 is left blank on the sender's communication 
board 400 (e.g., see the Ack field 420-3). Therefore, at all times a sender is able to 
determine the current status of their outgoing messages without needing to login to 
5 another service - i.e., the status is displayed through the visual cues presented on 
the communication board screen 400. 

In the preferred embodiment, information lines 402 for incoming messages have a 
hyperlink function such that selecting the underlined portion of the information line 
10 causes the application serveM 14 to return a reply screen/visual 162 that is partially 
filled out with the appropriate Recipient, Sender and Subject. The message reply 
procedures implemented in the present invention are described below, in reference 
to FIG. 5. There is no hyperlink function associated with the information lines of the 
outgoing messages. 

15 

As an example of these features, refer to FIG. 4B, which shows the communication 
board 400 for the user, "Mi? —The communication board 400 shows Mit has 9 
current messages and 4 open messages, which are messages that have not been 
closed/acknowledged). The underlined message headers are associated with 
20 replies to Mit and the plainly-displayed message headers are associated with 

messages sent by Mit This example includes four threads 460, 462, 464, 466. The 
thread 460 comprises two messages of the following levels: 

level 1 msg 442, to Arlene from Mit; and 

level 2 reply 444 to the level 1 msg; 

25 

Each message is displayed in open format, meaning that its text can be read without 
selecting/opening the message. For example the first level message 442 has the 
following openly displayed MsgText: 

"Pis order 3R report on 145 Piccadilly and give copy to Agnes." 

30 

The message 442 was r sponded to by Arlen , whose r ply 444 includes the 
following MsgText 

"3R report ord red. Will give copy to Agnes." 
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In response to Arlen 's 444, which clearly closed out the conversation, Mit sent an 
explicit acknowl dgement that caused the serv r application 1 14 to close the thr ad 
460. Thus, the Ack field 420-1 of the message 444 is shown underlined, indicating 
thread closure. 

5 

Due to the symmetry with which the message records are created (i.e, two message 
records created per communication pair), similar message information is displayed 
in real time on the communication boards of all participants to a thread; For 
example, referring to FIG. 4C, there is shown a portion of Arlene's communication 

10 board 400A listing some of the same threads 460, 462 as Mit's board 4Q&- In 
particular, Arlene's thread 460A and messages 442A, 444A correspond to Mit's 
thread 460 and messages 442, 444. Note that, on both boards 400 and 400A, the 
Ack information 420-1 for the corresponding messages 444 and 444A is identical. 
However, the information lines of the messages 444 and 444A differ. That is, on 

1 5 Mit's board, the information line of the message 444 (from Arlene to Mit) is 
underlined but, on Arlene's board, the corresponding information line is not 
uhdgflinea^This"because Afiene wa~s~the~senderof this"messageT"Other 
differences between Arlene's and Mit's boards are due to the fad that Arlene and 
Mit participate in different threads with different users. 

20 

A user can choose an alternative view of their messages by using the message 
review board feature of the present invention. A message review board presents a 
view of all messages in the user's message folder (i.e., stored messages) with a 
common subject For example, referring to FIG. 4D, which shows a message review 
25 board 1400, the threaded, instant messages shown are all associated with the same 
subject 1404 C145 Piccadilly") and are owned by the user, "Mit". The message 
review board presents the messages in the same manner as a communication 
board. The underlined message headers are associated with replies to Mit and the 
plainly-displayed message headers are associated with messages sent by Mit.The 
30 example of FIG. 4D includes three threads 1440, 1460, 1480. The thread 1440 
comprises three messag s of the following I vels: 

level 1 msg 1442, to Arlene from Mit 

level 2 reply 1444 to th level 1 msg; and 
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a lev 13 reply 1446 to th I vel 2 reply; 



Each message is displayed in open format, meaning that its text can be read without 
selecting/opening the message. For example the first level message 1442 has the 
5 following openly displayed MsgText: 

"Where are the signed copies of the TDS and Supp TDS? I need to provided 

copies to the lender." 



The message 1442 was responded to-by Arlene, whose reply 1444 is displayed on 
10 Mit's message review board 1400. Arlene's reply 1444 includes the following 
MsgText: 

"Buyer's agents will be dropping off signed copies tmo. I will go ahead and 
give copies of same to the Lender when I get them back." 



15 Mit replied to the reply 1444 with another reply 1446: 

"Thanks a whole lot. That will save me a lot of time. I owe you one!" 



By sending this reply 1446 Mit implicitly acknowledged the reply 1444 from Arlene. 
Consequently, the thread 1440 is still open and the server application 114 sets the 
20 date and time of the acknowledgment 1420-1 to the date and time (f 0-04-97 16:14) 
Mit sent the reply 1 446. 



In response to the reply 1446, which clearly closed out the conversation, Arlene 
sent an explicit acknowledgement that caused the server application 1 14 to close 
25 out the thread. Thus, the Ack field 1420-2 of the message 1446 is shown 
underlined, indicating thread closure. 

The preceding description is directed to an embodiment of the present invention 
where the communication boards are private and provide instant, open display of 
30 threaded messages. Alternative and equally novel embodiments of communication 
systems can employ various combinations of thes concepts (privacy, instant 
messaging, threading and open display). F r xample, the t achings of the pr s nt 
invention could be employed in the following nov I systems: 
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1 ) public bulletin boards with open display of messages; 

2) e-mail systems with open display of messages; 



3) e-mail systems with threading of messages; 

4) private bulletin boards with no other unique features; 
5 5) private bulletin boards with instant messaging; 

6) private bulleting boards with instant messaging and open display; and 

7) instant messaging systems with threaded of messages. 

Descriptions of these embodiments are not provided herein as their respective 
10 implementations should be apparent from the descriptions already provided. Other 
embodiments consistent with these teachings and descriptions will occur to the 
reader skilled in the art and are within the scope of the present invention. Having 
described the communication board concept, the message reply process is now 
described. 

15 

Referring to FIG. 5A ( there is shown a data flow diagram illustrating steps performed 
by a web~browser 1 68-1~of a message repliefTthe server application^ 14, and a web 
browser 168-2 of a message reply recipient for a message reply procedure. The 
steps illustrated in FIG 4A occur after the user of the client 150-2 has received a 

20 message (4.1) from a user of the client 150-1. Upon displaying a message on their 
communication board as described in reference to FIG. 4, a user can choose to 
reply to that message by selecting a reply option from a menu, an icon, or other 
equivalent methods (5.1). Once the user has selected the reply option a reply box is 
displayed (5.2) that allows the user to specify the reply's recipient and subject 

25 (these fields are filled in by default with the sender's information) and MsgText. The 
reply box description could be sent by the server application 1 14 or could be 
generated by the client application 166-1. The user fills in the reply (5.3), and then 
sends it off to the server application (5.4). Key information conveyed to the server 
in the reply includs the Msgld of the message responded to. 



30 



In response, the serv r application 114 assigns a uniqu MsgID to th r ply (5.5), 
generates corresponding message records 230 for the reply sender and recipi nt 
(5.6) and updat s database 108 records accordingly, including setting par nt and 
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child point rs to and from other message records 230 (5.7). Th serv r application 
114 then posts its reply to trie indicated recipients ( .g., the us r of the client 150-1) 
IF they are online (5.8). Note that, unlike first level messages, the server 
application 114 does not issue queries to recipients asking if they would like to a 
5 reply to be sent Instead, the server appliation 114 pushes replies to recipients. 
Morever, every time it pushes one reply, the server application 114 pushes all other 
replies held in abeyance (except for first level messages not yet accepted). An 
illustration of the databases 108 reflecting processing by the server application 114 
in response to a reply is now described in reference to FIG. 58. 

10 

Referring to FIG. 5B, there is shown an example of how, as a result of the reply 
processing performed by the server application 114, multiple records of the 
respective tables are generated and cross-referenced. FIG. 5B assumes a simple 
example where SueG has responded to the message sent by ArnieS (refer to 

1 5 ' discussion of FIG. 3B). Upon receiving the reply message the server application 
114 creates two new message records M005, M006 in the messages table 142. one 
One of these messages (Msgld=M005) lists AmieS as MsgRecOwner and Recipient 
and SueG as Sender. The other message (Msgld=M006) is similar, but lists SueG 
as MsgRecOwner and sender and ArnieS as Recipient A new Threads table 146 

20 entry has not been allocated as the subject (i.e., "The Lee Account 1 ') and subject 
index (S050) for the reply are already represented by the Thread T001 . Nor are 
newThreadParticpant table 148 entries allocated. This is because the two 
participants in the reply (AmieS and SueG) have appropriate records (with 
Participantlds = P021 and 032) in teh ThreadParticipants table 148. 

25 

Referring to FIG. 6, there is shown a data flow diagram illustrating steps performed 
by the web browser 168-1 of a message acknowledger and the server application 
1 14 for a message acknowledge procedure. The steps illustrated in FIG 4A occur 
after the user of the client 1 50-2 has received a reply message (5.7) from a user of 
30 the client 1 50-1 . A user can choose to acknowledge explicity a message displayed 
on th ir communications board 400 by selecting an Ack option from a menu, icon, or 
other equivalent means (6.1 ). In response, the client appliction/browser 166-2/166- 
3 relays pertinent information (including Msgld) for the messag being explicitly 
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acknowledged to th server application 114 (6.2). Th serv r application 114 
processes the messag acknowledgment as described in r fer nee to FIGS. 4A-4C 
and updates the databases 108 accordingly (6.3), principally by changing the status 
of the relevant message record to "ACKed" and completing the AckDate 256 (FIG. 
5 2). The server application 114 then posts the acknowledgement to the respective 
communications boards 400 of both participants (i.e., the sender using the client 
150-1 and the recipient using the client 150-2) as described in reference to FIGS. 
4B-4C (6.4). In a preferred embodiment the acknowledgment is only sent when the 
sender is online. 

10 

Alternatively, as described above, an acknowledgment can be sent implicitly as the 
result of a recipient of other than a first level message responding to that message. 
In this situation the server application 114 allocates new message records 230 in 
the same manner as for a reply (FIG. 5B); i.e., the Status 260 of those records is not 
15 listed as Acked and the AckDate 256 (FIG. 2) is not filled in. Additionally, the 
IsRespondedTo flag of the parent messages is set. 

An example of the databases 108 resulting from the processing of an 
acknowledgment is not shown given the similarity of these results to those in the 
20 reply case, already described in reference to FIG. 5B. 

In addition to the communication board features described above, the present 
invention provides additional conference, whisper, talk and mall modes. It is a 
key feature of the present invention that these modes are integrated with the 
25 communications board features. It is now described reference to FIG. 7 how the 
server application 114 supports conference mode. 

Referring to FIG. 7A, there is shown a flow chart illustrating steps by which the 
server application 114 schedules a conference, notifies conference participants and 
30 holds the conference. As the first step in scheduling a conference a user/moderator 
begins conference mod operations (702). The mod ratorth nschedul sa 
conference (704) by defining its: 
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participant (one or more users if conference is private, not nec ssary when 

conference is open); 

topic; 

data and time; and 

type (open or private), where open means that any user can participate in the 
conference and private means that a user can only participate if invited by the 
moderator. 

This information is entered by the moderator orTSTconferences page 162 generated 
by a browser 168 from information (typically fofmiatted as ACTIVE SERVER PAGES) 
forwarded by the server application 1 14. The completed conference page 162 is 
returned to the server application 114, which allocates a new record 270 in the 
conferences table 144 (706). The server application 114 updates the fields (706) of 
the new conference record 270 as follows: 

ID set to a unique ID generated by the application 114; 

Moderator set to the user name of the moderator; 

Topic set the topic defined by the user on the conferences 



Finally, the server application 114 schedules a virtual conference room for the 
future, or immediately, depending on when the conference is scheduled (706). 

Depending on when the conference is scheduled, at an appropriate time (which 
could be immediately or sometime in the future) (708-Y) the server application 114 
sends notifications to the conference participants (710). 



Type 

Participants 



When 



IsScheduIed 



page 162; 

set to type (open or private) selected by the moderator; 
set to particpants entered by the moderator, 
set to 1 if the user indicated that the conference is to be 
schedulred for future as opposed immediately; and 
date and time entered by moderator. 



As shown in FIG. 7B, which is an image of us r Mit's communication board 720 
including conference notifications and announcements, th notifications ar 
displayed similarly to messages (including the possibility of acknowledgements). 



In 
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particular, open confer nee notifications, such as the notifications 722, 728, are 
sent to all us rs, and private confer nee notifications, such as th notifications 746, 
752, and 756, are only sent to invited participants. Referring to an exemplary 
notification 722, all notifications display: 
5 a subject 740 that indicates the type of notification (e.g., PRIVATE 

CONFERENCE NOTIFICATION); 

the virtual conference room 742 (e.g., Room 1258); 

the date and time 744 of the conference (e.g., NOW); 

the-topic 746 (e.g., "Affect of new Health Ins Benefits"); and 
10 -an IN PROGRESS indication 748 if the conference is in progress. 

Note that private conference notifications can be acknowledged in the same manner 
as messages. For example, in response to the notification 732 from Arlene 
regarding a private conference to discuss future Christmas parties, Mit issued a 
15 confirming reply 734, which was later acknowledged 750 by Arlene. The 

acknowledgment 750 also closes the thread consisting of the messages 732, 734. 

FIG. 7B shows another feature of the present invention, announcements 724, 730, 
which are immediate messages broadcast to all users who are online. 

Referring again to FIG. 7A, at the scheduled time the server application 114 hosts 
the conference (714) by: 

allocating the virtual conference room; 

notifying all participants again that the conference is starting (e.g., the IN 
PROGRESS notification 722); 

and allowing the moderator to administer the conference in accordance with 
the type of conference (e.g., if the conference is public, users can join at will, 
but If the conference is private, users can only join at if invited by the 
moderator). 

On xample of a conference session screen 770 is shown in FIG. 7C. The scr en 
770 includ s an agenda 772 defined by the moderator, a comment sere n 774 on 
which comments typed by participants on their own conf r nee input sere ns are 



20 



25 



30 
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displayed and a list of participants 776. This screen 770 is displayed for all users 
who are participants in the conference by their respectiv brows rs 168. In a 
preferred embodiment all conference information is logged by the application server 
114 on the hard disk 104. The screen 770 includes an ANON button, which, when 
5 selected, allows a user to participate in the conference anonymously. 

A unique feature of the present invention is whisper mode, which is implemented in 
conjunction with conference mode. During a conference two users who wish to 
carry on a private, unlogged conversation can enter whisper mode. When in 
10 whisper mode users view their conversation on-arwhisper mode screen on which 
only their comments are displayed. No other user can view comments made by 
whisper mode participants. 

Referring to FIG. 8, there is shown an exemplary talk session dialog input screen 
15 800 in which a user (e.g., Arlene) enters a talk message 804 she would like to send 
to another user 802 (e.g, Mit) as part of a talk session. In the preferred 
embodiment, a user can start a talk session from any system mode other than 
conference mode. When the user is satisfied with the message 804, they select the 
send button 806, which causes the client application/browser 166, 168 to send the 
20 information from the talk session dialog input screen to the server application 114. 

The server application 1 14 then determines whether the intended talk session 
participant (e.g., Mit is online). If the intended participant is online, the server 
application 114 sends him a talk mode incoming message box, which announces a 

25 new incoming message and gives the intended participant the option of checking 
the message (i.e., joining in the talk session) or declining to participate. The 
incoming message box is displayed for the intended recipient no matter which mode 
his client 150 is in. If the intended participant declines to talk or is not available, the 
server application 114 sends the requestor (e.g., Arlene) a party not available 

30 message, indicating that the talk session cannot commence. If the intended 

participant is availabl and agrees to join th talk s ssion, th server application 
114 causes his client application/browser 166/168 to display the m ssage and gives 
him an opportunity to respond. 
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If the user lects to respond, he enters a message in a response input box and 
causes the appropriate browser 168 to send the information defined therein to the 
server application 114. The response input box is very similar to the talk session 
dialog input screen 800, shown in FIG. 8 and is therefore not described herein. 

5 Upon receiving the response, the server application 114 resends the first participant 
(e.g., Arlene) a dialog screen showing the second participant's response alongside 
the first participant's initial message. From this screen the first participant has the 
opportunity to send a reply back to the second participant. An exemplary talk dialog 
screen 820 for Arlene is shown in FIG. 8B. This screen shows in its upper section 

10 822 Arlene's initial message 824 and Mit's response 826. The screen 820 also 
includes a response input box 830 in which Arlene can enter a subsequent 
response. The talk session can proceed with screens like the screen 820 until one 
of the users signals an intention to exit the talk mode. 

15 As an example of the integration provided by the present invention, the server 
application 114 causes a incoming message alert to pop up during talk mode to 
notify a talk mode participant that he has a waiting communication board message. 
The alerted user can choose to check the message or CANCEL the alert, causing 
the server application 1 14 to initiate message processing operations already 

20 described in reference to FIGS. 4-6. While the user is checking his messages, the 
server application 114 causes the browser 168 used by the other talk session 
participant to display a talk session paused message. The talk session is re- 
activated when the participant checking his messages chooses to rejoin the talk 
session. 

25 

Talk session information is centrally maintained - in this case in a talk table 850 
(stored in the database 108). Unlike most other modes (except for whisper mode), 
talk messages are not logged on the hard disk 104 server; therefore, the talk table 
850 only includes a small set of status information for each talk session, in a 
30 preferred embodiment this status information includes: 

TalkS ssID Unique key for each talk s ssion g nerated by the 

server; 

FirstParticipant First participant user nam ; 
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ScndPartfcipant Second participant user name; 

InActiv Set to indicate that one of participants has not yet agre d 



to join session; 

MessageFIg Set to indicate that one of the participants has paused 

session to check a new message; 
MessageTS Date and time when participant paused session to check 

new message. 



The server application 114 allocates a single talk record for each new talk session. 
10 There is no need for the server application 1 14 to keep track of individual responses 
as talk sessions are not logged in the preferred embodiment. 

Another mode offered by the present invention is mail mode. Unlike conventional e- 
mail programs, in its mail mode the present invention is able to provide threaded 
15 mail over the Internet. An example of a mail screen 900 displayed for a particular 
user is shown in FIG. 9. 



The mail screen 900 lists mail received 902 and sent 904 by a particular user (e.g., 
Mit). Each incoming e-mail message is treated by the server application 1 14 as a 
20 level one message that begins a respective e-mail thread. Replies to the incoming 
e-mail messages are indented on the mail screen 900, visually indicating their 
position as second level messages in their associated thread. For example, the 
incoming e-mail messages 906, 908 and 910 all have replies 906a, 908b, 910c. 



25 Each of the incoming messages has a subject line (e.g., the subject 912 of the 
message 906) that is underlined. When a user selects the underlined subject line 
he prompts the server application 1 14 to return to the user's client 
application/browser 166/168 an e-mail reply box with most fields (such as sender, 
recipient, subject, date and time) already filled-in. The user then fills in the message 

30 text and sends the e-mail message. As with the other modes, after a reply is sent 
the mail screen 902 is immediately updated by the server application 1 14 with th 
threading information. Outgoing mail is handled in the same manner exc pt for the 
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problem that threading information may not b maintained by external e-mail servers 
that r ceive the outgoing messages. 



As with the other system modes, e-mail information is centrally maintained - in this 

5 case in a mail table 920 (stored in the database 1 08) whose fields include: 

MalllD Unique key for each email message generated by the 

server; 

MailTimeStamp Date and time message was sent or received; 

Sender Sender Name; 

10 SenderAdr Sender e-mail address; 

Reclplerff" Recipient Name; 

RecipientAdr Recipient e-mail address; 

Threadld Unique Id for each mail Thread; 

ThreadLevel Top level messages have level = 1, 
15 Replies have level = 2; 

Subject Message subject; and 

MsgFN Name of file on hard disk 1 04 where MsgText is stored. 

The server application 1 14 allocates a mail message record for each new e-mail 
20 (outgoing, incoming, or reply) and updates these e-mail fields in much the same way 
as in the message situation described above. As a result, the processing of e-mail 
messages by the present invention is not further described. 



While the present invention has been described with reference to a few specific 
25 embodiments, the description is illustrative of the invention and is not to be 

construed as limiting the invention. Various modifications may occur to those skilled 
in the art without departing from the true spirit and scope of the invention as defined 
by the appended claims. 
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WHAT IS CLAIMED IS: 

l! A system for threaded instant messaging for use in a network of computers 
including a server computer, comprising: 
5 a server mechanism executable in the server configured to make instantly 

available to a user who is logged onto the server representations of messages sent 
to the user and to maintain threading information associated with the messages; 

the server mechanism also being configured to display-the representations of 
messages to the user along with a representation of the threading information. 

10 

2. The system of claim 1 , wherein the server mechanism-is- configured to display 
the representations in an open format wherein the messages do not need to be 
selected to be read. 

15 3. The system of claim 1 , wherein the server mechanism is configured to display 
the representations on a private message board that only shows communications 
sent to and by the user and which can be viewed only by the user. 

4. The system of claim 3, wherein the server is configured to maintain a plurality 
20 of private message boards, one for each user of the system; such that, whenever a 

representation of the message is displayed on the private message board of one 
participant in the message, a corresponding representation of the message is 
displayed nearly simultaneously on the private message board of another 
participant in the message. 

25 

5. The system of claim 1 , wherein the server mechanism is configured to enable 
users to acknowledge messages; such that, when the user acknowledges a 
particular message, the server mechanism notifies a second user who is a 
participant in the message of the user's acknowledgment of the particular message. 

30 

6. The system of claim 5, wh r in the acknowledgment can be explicit or 
implicit, such that: 
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when the acknowledgment is explicit, th server mechanism closes a thread 
including the particular m ssage; and 

when the acknowledgment is implicit, the server mechanism leaves open the 
thread including the particular message, the implicit acknowledgment occurring 
5 whenever the user replies to the particular message. 

7. The system of claim 6, wherein the explicit acknowledgment is employed by 
the user to manifest acceptance of/agreement to contents of the message. 

10 8. The system of claira-1 , wherein the server mechanism is configured to queue 
at the server at least a subset of the messages addressed to the user without 
displaying to the user the representations of the subset until the user has approved 
transmission of at least one of the messages in the subset, after which the server 
mechanism displays the representations of the subset to the user. 

15 

9. The system of claim 1 , wherein the server mechanism displays the 
representation of the message along with a hyperlink field, the selection of which by 
the user causes the server mechanism to display to the user a reply window with at 
least some fields filled out with information associated with the hypertext field, 

20 enabling the user to formulate a reply to the sender of the message. 

10. The system of claim 1 , further comprising: 

a message table including message records, each of which is associated with 
a message having a sender, recipient, owner and subject; 

25 such that, whenever the user sends a message to N other users, the server 

mechanism allocates 2 x N message records, N of which have respective ones of 
the other users as the owner and the other N of which have the user as the owner, 
all of the 2 x N messages having the same sender and subject, respective pairs of 
the 2 x N messages listing as the recipient a respective one of the other users; 

30 the server mechanism being additionally configured to display for each of the 

N + 1 users only thos message for which h is owner. 



WO 99/48011 - PCT/US99/06074 

-38- 

1 1 . The system of claim 1 0, wherein the server mechanism nables each of th 
users to manipulate only those messages for which he is the owner. 



12. The system of claim 1 1 , wherein messages with the same subject, sender, 
5 recipient and message text are displayed nearly simultaneously to the respective 

owners of the messages. 

13. A system for open display bulletin boards for use in ar network of computers 
including a server computer, comprising: 

10 a server mechanism executable in the server configured to provide a bulletin 

board system wherein messages submitted to the bulletin board by users of the 
network are displayed with threading information and in an open format wherein all 
messages are displayed in full and do not require prior selection for viewing. 

15 14. The system of claim 1 3 wherein the server mechanism is configured to 

display the messages on a plurality of private message boards, each of which only 
shows communications sent to and by a respective user and which can be viewed 
only by the respective user. 

20 1 5. The system of claim 14, wherein, whenever a first representation of a 

particular message is displayed on the private message board of one participant in 
the particular message, a corresponding representation of the particular message is 
displayed nearly simultaneously on the private message board of another 
participant in the particular message. 

25 

16. The system of claim 13, wherein the server mechanism is configured to 
enable users to acknowledge messages; such that, when the user acknowledges a 
particular message, the server mechanism notifies a second user who is a 
participant in the particular message of the user's acknowledgment of the particular 

30 message. 

17. The system of claim 16, wherein the acknowledgment can b xplicit or 
implicit, such that: 
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when the acknowledgment is explicit, the server mechanism clos s a thread 
including the particular message; and 

when the acknowledgment is implicit, the server mechanism leaves open the 
thread including the particular message, the implicit acknowledgment occurring 
5 whenever the user replies to the particular message. 

18, The system of claim 17, wherein the explicit acknowledgment is employed by 
the user to manifest acceptance of/agreement to contents of the particular message. 

10 19. The system of claim-1 3, wherein the server mechanism is configured to 

queue at the server at least-a subset of the messages addressed to the user without 
displaying the representations of the subset until the user has approved 
transmission, after which the server mechanism displays the representations of the 
subset to the user. 

15 

20. The system of claim 1 3, wherein the server mechanism displays the 
^representetrorvof tt^mesOT 

the user causes the server mechanism to display to the user a reply window with at 
least some fields filled out with information associated with the hypertext field, 
20 enabling the user to formulate a reply to the sender of the message. 

21 . The system of claim 1 3, further comprising: 

a message table including message records, each of which is associated with 
a message having a sender, recipient, owner and subject; 

25 such that, whenever the user sends a message to N other users, the server 

mechanism allocates 2 x N message records, N of which have respective ones of 
the other users as the owner and the other N of which have the user as the owner, 
all of the 2 x N messages having the same sender and subject, respective pairs of 
the 2 x N messages listing as the recipient a respective one of the other users; 

30 the server mechanism being additionally configured to display for each of the 

N + 1 users only those message for which he is owner. 
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22. The syst m of claim 21, wherein the server mechanism enables each of the 
users to manipulat only messages of which he is the owner. 



23. The system of claim 22, wherein messages with the same subject, sender, 
5 recipient and message text are displayed nearly simultaneously to the respective 

owners of the messages. 

24. A private message board system for use in a network ofcomputers including 
a server computer, comprising: 

10 a server mechanism executable in the server configured to provide a plurality 

of private bulletin boards for each of a plurality of users of the -system, wherein each 
of said private bulletin boards shows history of messages associated with 
conversations involving a respective user. 

1 5 25. The system of claim 24, wherein the server mechanism is configured to 
display representations of the messages in an open format wherein the messages 
donot need toTJeselected to^be read; 

26. The system of claim 24, wherein the server mechanism is configured to 
20 display nearly simultaneously with its posting a particular message on the private 

message boards of all participants in the message. 

27. The system of claim 24, wherein the server mechanism is configured to 
enable users to acknowledge messages; such that, when the user acknowledges a 

25 particular message, the server mechanism notifies a second user who is a 

participant in a thread containing the thread of the user's acknowledgment of the 
particular message. 

28. The system of claim 27, wherein the acknowledgment can be explicit or 
30 implicit, such that: 

when the acknowledgment is explicit, th server m chanism clos s the thread 
including the particular message; and 
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when the acknowledgment is implicit, the server mechanism ieav s op n the 
thread including th particular message, the implicit acknowledgm nt occurring 
whenever the user replies to the particular message. 

5 29. The system of claim 24, wherein the server mechanism is configured to 

queue at the server at least a subset of the messages addressed to the user without 
displaying the representations of the subset until the user has approved 
transmission, after which the server mechanism displays the representations of the 
subset to the user. 

10 

30. The system of claim 24, wherein the server mechanism displays a 
representation of the message along with a hyperlink field, the selection of which by 
the user causes the server mechanism to display to the user a reply window with at 
least some fields filled out with information associated with the hypertext field, 
15 enabling the user to formulate a reply to the sender of the message. 

— "^Slr. — The^ystenrxifxlainr^ 

a message table including message records, each of which is associated with 
a message having a sender, recipient, owner and subject; 

20 such that, whenever the user sends a message to N other users, the server 

mechanism allocates 2 x N message records, N of which have respective ones of 
the other users as the owner and the other N of which have the user as the owner, 
all of the 2 x N messages having the same sender and subject, respective pairs of 
the 2 x N messages listing as the recipient a respective one of the other users. 

25 

32. The system of claim 31, wherein messages with the same subject, sender, 
recipient and message text are displayed nearly simultaneously on the private 
message boards of the respective owners of the messages. 



30 



33. A communication board system for use in a computer network including a 
server, comprising: 

a server application executable on the server; and 
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a client application providing an interface between system us rs and the 
server application; 

such that said client application and server application are configured 
cooperatively to provide each of said users with a respective view of a virtual 
5 bulletin board system illustrating history and content of at least a subset of said 
. messages, said respective view being instantly accessible to and customizable for a 
corresponding one of said users. 

34. The communication board system of claim 33, wherein the server application 
10 and the client application are browser-based, enabling the communication board 

system to be implemented on any computer network compatible-with Internet-based 
protocols. 

35. The communication board system of claim 34, wherein the computer network 
15 is selected from: 

the Internet; 

an intranetror 

an extranet 

20 36. The communication board system of claim 33, wherein said respective view 
includes only those of said messages associated with conversations to which said 
corresponding user is a participant. 

37. The communication board system of claim 33, further comprising: 

25 a data repository in which the server application stores information about 

system users and messages exchanged between said users. 

38. The communication board system of claim 37, wherein the data repository 
comprises: 

30 a message table including message records, each of which is associated with 

a messag having a sender, recipient, owner, subj ct and thr ad id; 

such that, wh never a user sends a messag toNoth r users, the server 
application allocates a message family of 2 x N message r cords, N of which have 
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respective ones of th other users as the owner and the other N of which have the 
first user as the owner, all of the 2 x N messag s having the same sender, subject 
and thread id, respective pairs of the 2 x N messages listing as the recipient a 
respective one of the other users, the sending user and other users being thread 
participants. 

39. The communication board system of claim 36, wherein messages with 
identical subject, sender, recipient and thread id can be provided nearly 
simultaneously on the respective views provided to the respective owners of the 
messages. 

40. The communication board system of claim 38, wherein, when a first user 
sends a first level message to a second set of users using the client application, the 
server application is configured in response to: 

allocate the family (first level family) of message records for the first level 
message; 

- —g enerate-a-unique thread id-and associate the unique thread id with each of 
the first level family; 

update each member of the first level family with the sender, recipient, owner 
20 and subject information for a respective thread participant; 

issue a message alert to the client applications of each of the other users; 
transmit a representation of a respective message record to the client 
application of each of the second set of users who agrees to delivery of the 
message; and 

25 hold in abeyance transmission of a representation of a respective message 

record to each of the second set of users who does not agree to delivery of the 
message. 

41 . The system of claim 40, wherein, when a third user sends a reply to a 

30 message from a fourth user using the client application, the server application is 
configured in response to: 

allocate the family (r ply family) of message records for the reply messag ; 



10 



15 
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associate the unique thread id from a parent family with each member f the 
reply family, the parent family being the message records associated with the 

messag e from the^ourth user; 

update each member of the reply family with the sender, recipient, owner and 
5 subject information for a respective participant in the reply message; 

link members of the reply family with related message records of the parent 
family; and 

transmit a representation of a respective reply message record to the client 
application of the fourth user. 

10 

42. The communication system of claim 41 , wherein, when a third user explicitly 
acknowledges an incoming message using the client application, the server 
application is configured in response to: 

update the message records associated with the thread that includes the 
15 incoming message to show that the thread is closed; 

transmit a representation of the incoming message to the client applications 
of participants in the thread that includes the incoming message conveying that the 
thread is dosed. 

43. The communication system of claim 41 , wherein, when a third user implicitly 
20 acknowledges an incoming message using the client application, the server 

application is configured in response to: 

update the message records associated with the thread that includes the 
incoming message to show that the thread is responded to; 

transmit a representation of the incoming message to the client applications 
25 of participants in the thread that includes the incoming message conveying that the 
thread is responded to. 

44. The communication board system of claim 36, wherein the respective views 
display representations of the messages in an open format wherein the content of 

30 the messages can be read without selecting the messages. 



45. The communication board system of claim 36, wherein the resp ctive vi ws 
display the repres ntation of a messag along with a hyperlink field, the selection of 
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which by the user causes the server and client applications coop ratively to display 
to the user a reply window with at least some fields fill d out with information 
associated with the hypertext field, enabling the user to formulate a reply to the 



message. 

5 

46. A method for threaded instant messaging for use in a computer network, 
comprising the steps of: 

displaying messages sent over the network involving a user of the network so 
that only said user can view messages sent and received by said user; 
10 displaying said messages in an open format so that content of said messages 

is viewable without selection;and 

immediately making said messages available for viewing by said user 
whenever said user is online. 

1 5 47. The method of claim 46, further comprising the steps of: 
maintain threading information of said messages; and 
— ^^displaying^a^representatiorfofsaid^threading information^along withrsaid 
messages. 

20 48. The method of claim 46, further comprising the steps of: 

whenever a user sends a message to N other users, allocating a message 
family of 2 x N message records, N of which have respective ones of the other users 
as the owner and the other N of which have the first user as the owner, all of the 2 x 
N messages having the same sender, subject and thread id, respective pairs of the 

25 2 x N messages listing as the recipient a respective one of the other users, the 
sending user and other users being thread participants. 

49. The communication board system of claim 48, further comprising the steps of: 
when a first user sends a first level message to a second set of users: 
30 allocating the family (first level family) of message records for the first 

level message; 

generating a unique thread id and associat the unique thread id with 
each of the first I vel family; 
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updating each member of the first lev I family with the sender, 
recipient, owner and subject information for a respective thread participant; 

issuing a message alert to each of the other users; 

transmitting a representation of a respective message record to each 
5 of the second set of users who agrees to delivery of the message; and 

holding in abeyance transmission of a representation of a respective 
message record to each of the second set of users who does not agree to delivery 
of the message. 

1 0 50. The method of claim 49, further comprising the steps of: 

when a third user sends a reply to a message from a fourth user, 

allocating the family (reply family) of message records for the reply 

message; 

associating the unique thread id from a parent family with each 
15 member of the reply family, the parent family being the message records associated 
with the message from the fourth user; 

updatingiB'a^ffr^berof the replyTamilywitlrthe senderfrecipient, 
owner and subject information for a respective participant in the reply message; 

linking members of the reply family with related message records of 
20 the parent family; and 

transmitting a representation of a respective reply message record to 
the fourth user. 



51 . The method of claim 50, further comprising the steps of: 
25 when a third user explicitly acknowledges an incoming message, 

updating the message records associated with the thread that includes 
the incoming message to show that the thread is closed; and 

transmitting a representation of the incoming message to participants 
in the thread that includes the incoming message conveying that the thread is 
30 closed. 



52. 



The method of claim 50, further comprising the steps of: 

wh n a third us r implicitly acknowledges an incoming message, 
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updating the message records associated with the thread that includes 
th incoming messag to show that the thread is r sponded to; and 

transmitting a representation of the incoming message to the client 
applications of participants in the thread that includes the incoming message 
conveying that the thread is responded to, 

53. A system for memorializing agreement for use in conversations and 
negotiations conducted via an electronic communication system, comprising: 

a server program that opens a thread corresponding to each conversation 
ongoing in the communication system; 

a data repository in which the server program records status and content of 
messages composing said conversation; and 

a client program configured to cooperate with said server program to enable 
users of the electronic communication system to view and respond to said 
messages; 

a user response including acknowledgment, wherein a user signifies 
agreemenfto a partTSilar messag^by acRrfSWl^dgihg said'piRt^^message, said 
client program being configured to relay said acknowledgment to said server 
program, which is configured to close said particular message's thread and update 
said data repository to show said status of said particular message is 
acknowledged. 

54. A threaded e-mail system for use in a computer network, comprising: 

a server application running in a server attached to the computer network; 
25 an e-mail database; 

a client application employed by users to interact with the server application 
to perform e-mail operations, including exchanging e-mail with external 
correspondents and viewing e-mail messages and e-mail status; 

the server application being configured to allocate a first new record in the e- 
30 mail database corresponding to each new incoming e-mail and to associate each of 
the first new records with a unique e-mail thread id; 

the server application being configured to allocat a second new r cord in 
the e-mail database corresponding to each reply to the incoming e-mail and to 



10 



15 



20 
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associate ach of th second new records with the unique -mail thread id of th 

incoming e-mail repli d to; and 
the server appIicatlofT^ingconfipred topreBentinformation^thec^rt" 

application from the e-mail database enabling the client to display the e-mail 
5 messages and e-mail status including threading information showing common 

subject matter and history of the incoming e-mail and the replies thereto issued by 

respective user. 
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COMMUNICATION BOARD SYSTEM AND METHOD 
FOR USE IN COMPUTER NETWORKS 

The present invention relates generally to electronic communication systems for use 
in computer networks and, particularly, to bulletin boards, instant messaging 
systems, electronic mail and chat rooms. 

5 

BACKGROUND OF THE INVENTION 



An"electronic communication system for use in enterprise and other collaborative 

environments would ideally include a suite of capabilities that facilitate decision 

10 making and communication by two or more individuals. Such capabilities could 
include: 

• enabling users to view the history of multiple conversations with 
multiple parties (referred to hereinafter as "conversation history*); 

• enabling users to view messages as soon as they are available 

15 without requiring the users to log onto a public bulletin board system 

(BBS) (referred to hereinafter as "instant access 9 ); 

• enabling users to view the content of messages without requiring that 
the messages first be selected (referred to hereinafter as "open 
display"); 

20 • enabling users to conduct their conversations in privacy so that each 

user is the only person who can view the history and content of their 
respective multiple conversations (r ferred to her inafter as "private 
conversations"); 
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• enabling users to undeniably agre to proposals made in the course of 
a conversation in such a way that th conversation is concluded 
(referred to hereinafter as "agreement"); and 

• enabling users to participate in moderated conferences or informal 
5 chats, as well as in conversations (referred to hereinafter as 

"integrated modes"). 

Prior art electronic systems, which include electronic mail (e-mail), bulletin board 
systems (BBS), instant messaging and chat rooms, offer some but not all of these 
10 capabilities and, as a result, are less then ideally suited to enterprise 

communications. The capabilities of these various communication systems are 
presented in Table 1 . 



TABLE 1 




System 


Conversation 


Instant 


Open 


Private 


Agreet 


Integrated 




History 


Access 


Display 


Conversations 




Modes 


E-mail 


No 


Yes 


No 


Yes 


No 


No 


BBS 


Yes 


No 


No 


No 


No 


No 


Instant 


No 


Yes 


Yes 


Yes 


No 


No 


Messaging 














I Chat 


No 


Yes 


Yes 


No 


No 


No 



Referring to Table 1, e-mail systems offer instant access to messages, but the 
messages must be selected and opened by the recipient (typically with a mouse 

25 click) to be viewed. E-mail messages are private as they are directed to specific 
recipients (one or many). No viewable history is available for E-mail messages 
except for the most rudimentary kind wherein a message being replied to can be 
copied into the body of the response. E-mail has only one mode and includes no 
feature whereby an e-mail user can issue a formal agreement to a proposal 

30 contained in a message, other than so stating in a reply message; e.g., *l agree to 
your proposal of 12/10/97 on the subject of contract t rms." 
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Like e-mail syst ms, bulletin board systems (BBS) do not provide open display, 
agreement, r int grated mode capabilities. Unlike E-mail systems, BBS display 
messages in a threaded format wherein a topic is listed first and all messages 
germane to that topic are listed below the topic with different levels of indentation 
5 indicating historical and logical relationships between the related messages. For 
example, a BBS might display a topic and two messages on the topic, the first 
having an associated comment, as follows: 
Topic: Discussion of X 
Message 1 

-tO Comment on Message 1 

Message 2 

Because BBS do not provide open display, a user must select a message or 
comment to read that message or comment. BBS are centralized systems, meaning 
that a user must actually log in to the BBS to view topics and messages. As a 
15 result, messages are not immediately accessible (i.e., to read messages on a topic 
of interest a user must first access the BBS). Also, BBS are anything but private; 
typically, the same BulletirTBoarcl i^available^toall users, meaning that all 
messages are accessible to all users. 

20 Instant messaging systems allow users to communicate privately in real time over a 
network connection. An example of such a system is America On Line's "Instant 
Messages" feature, which allows an AOL member who is online to communicate with 
another member who is also online at the same time. Messages are openly 
displayed (i.e., without needing to be selected first). Thus, instant messaging 

25 systems provide private conversations, immediate access and open display 
capabilities. However, instant messaging systems do not support conversation 
history, agreement or integrated modes. Moreover, instant messaging systems are 
for one-on-one communication only. 

30 Chat systems allow a group of users to enter a chat room and then engage in a 
group conv rsati n. The group conv rsation can be moderat d or un-moderat d. 
Like instant messaging, chat systems are for informal communications and do not 
provide conversation history, agreement or integrated mod s. Also like instant 
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messaging, chat syst ms openly display all messages. Howev r, chat messages 
are not immediately accessible as a user needs to nter a chat room before they 
can view messages. Also, chat rooms are not private as anyone in the chat room 
can read all chat messages typed by users in that room. 

5 

Consequently, there is a need for an enterprise communication system that provides 
features and/or combinations of features not present in prior art electronic 
communication systems. 

10 

SUMMARY OFTHE INVENTION 

In summary, the present invention is a electronic communication system that 
provides features and/or combinations of features not present in prior art electronic 
15 communication systems. In particular, the present invention is a communication 
board system with multiple modes in which the communication board system can be 
— variously configured as: 

• a threaded instant message system (conversation history plus instant 
access capabilities); 

20 • an open display bulletin board system (conversation .history plus open 

display capabilities); 

• private message boards (conversation history plus private 
conversations capabilities); 

• a system allowing message locking (conversation history plus 
25 agreement capabilities); and 

• a threaded mail system. 

The preferred embodiment of the system is implemented as a client server system 
including a server application, a client application and a data repository resident on 
30 the server. In the preferred embodiment a sender requests communication services 
using his client application, which relays th r quest to th serv r program. Th 
server program updat s the data repository to r fleet the request and th nissu san 
appropriate message to the client application of one or more recipients, d pending 
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on the requested communication services. Any response by a r dpi nt is 
cooperatively handled by the client and server applications in the same mann r as 
the initial request. All communications activities are moderated by the server 
application and recorded in the data repository. 

5 

The data repository is preferably structured as a set of relational database tables, 
including a users table and a messages table. The users table lists characteristics 
-of all system users, including unique ID, name and preferences. The messages 
table lists characteristics of each message issued by users, including a unique 
10 -message ID, threading information (parent and child message IDs) sender and 
recipient name, subject, status of the message (unread, read, responded, 
acknowledged, etc. ), type of message (thread, invitation, confirmation, log), 
miscellaneous flags, and the name of the file where the message text is stored on 
the server. 

15 

In the preferred embodiment a sender sends a message to a recipient by filling in a 

-send-message-template-displayed-by-the client-application r whieh relays the 

completed message information to the server application. Upon receiving the 
message information the server application stores the pertinent information (sender, 

20 recipient, subject) in the message table, updates message status fields and 

threading information for the same message table record, stores the message text in 
a file, and issues the client application of the intended recipient a pending-message 
alert Preferably, the server application sends the pending-message alert only when 
the users table indicates that the recipient is online, although this is not a 

25 requirement of the present invention. The client application gives the recipient an 
opportunity to do nothing, cancel the alert, or accept the message. If the user does 
nothing, the server resends the alert at some prescribed interval. If the user cancels 
the alert, the server will not resend the alert and places the message on hold. If the 
user accepts the message, the server sends the relevant message information to 

30 the client application to be accessed by the recipient. 

When the preferred embodiment is configur dasaprivat messag board system, 
each user interacts with the communication system via a private bulletin board in 
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which the client application instantly displays the history and content of all 
messages associated with conversations in which the respective user is a party. In 
this configuration the present invention supports multiple instances of instant 
messaging, meaning that it provides private bulletin boards for multiple users and is 

5 able to allow each of the multiple users to exchange instant messages with one or 
more other users. In this case the relevant message information returned by the 
server application to the intended recipient includes threading information, which 
enables the client application to display the message's history along with that of 
other messages. Preferably, the client application displays the messages in open 

10 format; however, the client application could also display the messages in the 
conventional format. 

Once a recipient has accepted a message, he can reply to or acknowledge the 
message. The message reply feature is implemented cooperatively by the client 

15 and server applications in the same manner as the message send feature. 
Message acknowledge is a feature of the present invention wherein a 

— ^^conversation's thread is closed, indicating that the conversation has been 

concluded, typically with some agreement. For example, a user can indicate final 
acceptance of sales terms set out in the last of several threaded messages by 

20 acknowledging that message. The client application relays message acknowledge 
information to the server application, which updates the data repository by setting 
the message status to acked and closing the corresponding thread. Thus, the 
present invention allows the entire history of a negotiation to be preserved along 
with its final agreement. 

25 

The other system configurations can be implemented using the components of the 
preferred embodiment with minimal changes from the above description. 

In the preferred embodiment, the client application is based on a web browser and 
30 the server application includes communication board software that performs all high 
level and data repository operations and web server softwar that decodes and 
encodes communications from and to the client web browser. Pr ferably, all 
communication board contents displayed to users are formatted as ACTIVE 
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SERVER PAGES whose fi Ids can be dynamically filled in by the user via the client 
web browser or by the server's communication board software using information 
from other users and/or the data repository. 

5 Another feature provided by the preferred embodiment is message hyperlinking, 
which allows a user to form a response to any message shown on their private 
bulletin board by simply selecting a hypertext link identifying the message sender. 
In response to the selection of a hyperlink the client application generates the 
appropriate response screen with some of the fields (e.g., sender, recipient, subject) 

10 filled-in. 

The preferred embodiment supports multiple integrated modes, including a threaded 
communications (message) mode, already described, talk mode, conference mode, 
whisper mode and mail mode. The present invention allows users to transition 
1 5 smoothly between the modes. 

— =eonference"mode"aHows^tjsers to^articipate^n = moderated-or-unmoderated 

conferences that are scheduled or unscheduled. Information regarding conference 
participants and scheduled time and moderator, if applicable, are stored by the 

20 server application in a conferences table within the data repository. When a user is 
to participate in a scheduled conference he is notified of the virtual conference room 
and time of the conference by the server application. The server application also 
creates the virtual conference room at the appropriate time, registers participants, 
and stores a log of the conference in the data repository. In a preferred 

25 embodiment conference mode conversations are unthreaded. Whisper mode is 
available to participants in a conference who wish to paricipate in a private, side 
conversation. 

Talk mode allows users to participate in informal, unlogged conversations. In a 
30 preferred embodiment talk mode conversations are unthreaded. 

Mail mode allows a user to send e-mail over the Intern t with two levels of 
threading. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



Additional objects and features of the invention will be more readily apparent from 
5 the following detailed description and appended claims when taken in conjunction 
with the drawings, in which: 

FIG. 1 is a block diagram of a preferred embodiment of tha-present invention; 

10 FIG. 2 is a block diagram of the database tables 140, 142.144, 146, 148 from FIG. 
1; 

FIG. 3A is a data flow diagram illustrating the relationships between a client 
application 166 and web browser 168, the web server 116, the server application 
15 114 and the PMB databases 108 when a user is sending a message; 

FIG,-3B4^a-block diagram-of-new-records allocated _in-the_various tables by the 

server application 1 14 while processing an exemplary send request; 

20 FIG. 4A is a data flow diagram illustrating steps performed by the web browser 168- 
1 of a message sender, the server application 114 and the web browser 168-2 of a 
message recipient for a message send procedure; 

FIG. 4B is an image of a private communication board screen on which instant 
25 messages owned by one user are presented in a threaded, open format; 

FIG. 4C is an image of a second private communication board screen on which 
instant messages owned by a second user are presented in a threaded, open 
format; 

30 

FIG. 4D is an imag of a private message review board that presents for one user 
all of the user's messages having a common subject; 
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F1G. 5A is a data flow diagram illustrating steps performed by a web brows r 168-1 
of a message replier, the server application 114, and a web browser 168-2 of a 
message reply recipient for a message reply procedure; 

5 FIG. 5B is a block diagram of new records allocated in the various tables by the 
server application 114 while processing an exemplary reply request; 

FIG. 6 is a data flow diagram illustrating steps performed by the web browser 168-1 
of a message acknowledger and the server application 1 14 for a message 
1 0 acknowledge procedure; 

FIG. 7A is a flow chart illustrating steps by which the server application 1 14 
schedules and implements a conference; 

15 FIG. 7B depicts an exemplary communications board for a particular user illustrating 
conference notifications and announcements; 



FIG. 7C depicts a conference screen displayed by client Web browsers 168 for all 
clients participating in a conference; 

20 

FIG. 8A is depicts a talk entry screen displayed by client Web browsers enabling a 
user to transition to talk mode; 

FIG. 8B is depicts a talk session screen displayed by client Web browsers during a 
25 talk session; and 

FIG. 9 depicts a mail screen displayed by client Web browsers that supports 
threaded Internet e-mail. 



30 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 



"Referring to FIG. 1, there is shown a block diagram of a preferred embodiment of 
the present invention. This embodiment includes a server 100 with a server memory 
106, processor 102, hard disk 136 and database 108. The server memory 106 could 
be any combination of a RAM or cache memory and includes an operating system 
1 10, application programs 1 12 and data 118. In accordance with well known 
principles, the processor 102 executes the applications 1 12 in the memory 106 
under control of the operating system 110. 



10 



The applications 112 include a personal message board (PMB) server application 
embodying many of the teachings of the present invention and a web server 116, 
which could be any program configured to serve web content over a network. The 
applications 112 also include communications application 117, which are programs 

1 5 that employ features of the server application 1 1 4. The data 1 1 8 include ACTIVE 
SERVER PAGES (ASP) 120 that describe the contents of web pages through which 
,^^clientsJ:50.exercise^ 

conferencing (incorporating a whisper mode for conference participants), talk, and 
mail. The ASP 120 therefore includes a messages page 122, a conference page 

20 124, a whisper page 126, a chat page 128, a mail page 130 and other pages 132 
needed for miscellaneous client-server communications. 

Message mode allows a user to interact with a private bulletin board in which his 
messages (Le., any message involving the user as sender or recipient) are instantly 

25 available and displayed with full threading information. Message mode supports an 
acknowledge (Ack) reply which, when sent by a user in response to a particular 
message, closes the thread comprising the particular message and records the 
users acknowledgment that they read/accepted the message. Because each 
bulletin board is private, no user other than the authorized user can view its 

30 contents. 



Conference mode allows users to participate in moderated or unmoderated 
conferences that are schedul d or unscheduled. Information r garding conference 
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participants and sch duled time and moderator, if applicable, are stored by th 
server application in a conferences table within the data repository. When a user is 
to participate in a scheduled conference he is notified of the virtual conference room 
and time of the conference by the server application. The server application also 
5 creates the virtual conference room at the appropriate time, registers participants, 
and stores a log of the conference in the data repository. In a preferred 
embodiment conference mode conversations are unthreaded. Users involved in a 
conference can enter whisper mode, in which they can converse privately, without 
logging. 
10 — 

Talk mode allows users to participate in informal, unlogged conversations. In a 
preferred embodiment talk mode conversations are unthreaded. Mail mode allows 
a user to send threaded e-mail over the Internet. Each of these modes is integrated 
so that users can transition from one to the other. 

15 

In the preferred embodiment, the database 108 is a relational database system 
including tables organized to store information written and retrieved by the server 
application 114 in the course of its operation. The database tables include a users 
table 140, messages table 142, conference table 144, threads table 146 and a 

20 thread participants table 148. The tables 140-148 respectively store information on: 
system users (140), messages exchanged between users (142), conferences of 
users (144), mapping of messages to threads (146), and mapping of thread 
participants (users) to threads (148). These tables are described in depth in 
reference to FIG. 2. The hard disk 104 includes message files 136, which store the 

25 text of messages referred to by the messages table. 

The embodiment shown in FIG. 1 also includes one or more clients 150, each of 
which is used by one or more users. The single client 150 shown is representative 
of the one or more possible clients. In the preferred embodiment, clients 1 50 are 
30 coupled to the server 102 via an intranet 160; however, the principles of the present 
invention are qually applicable to any type of network, such as th Intern t, an 
extranet or combinations thereof. Th client 150 and the s rver 100 exchange 
information over the n twork 160 using standard network protocols, such as TCP/IP 
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and HTTP. In particular, the server application 114 makes availabl to users 
communication board services (encompassing private messag boards, chat, talk, 
conferencing and mail) by transmitting to the clients 150 via the web server software 
1 16 manifestations of the ACTIVE SERVER PAGES 120 and other web pages. 
5 These manifestations, when displayed by the clients 150, enable the users to view 
communications board information and messages from other users, and to issue 
requests and queries to the PMB application 1 14 via the web server software 116. 

The client 150 includes a memory 156, processor 152, hard disk 154 and user 
10 interface elements 158, such as a display, keyboard and selection device. The 
memory 156 could be any combination of a RAM or cache memory and includes an 
operating system 162, application programs 164 and data 170. In accordance with 
well known principles, the processor 152 executes the applications 164 in the 
memory 156 under control of the operating system 162. 

15 

The applications 164 include a personal message board (PMB) client application 
— =166-and-aweb-browseM€8=The web^browser^STeceivesftransmitsrand 

presents manifestations from the ASP 120 and other pages transmitted over the web 
by the server application 1 14 via the web server 1 16. The client application 166 

20 provides additional processing capabilities not present in the web browser 168 to 
assist users in interacting with the communication board features. These additional 
processing capabilities can include: responding to alerts from the PMB application 
114 when the user is not available, locally logging user sessions, maintaining a local 
address book for the user and issuing standard queries or requests to the server 

25 application 114. Note that simple implementations of the present invention can 
eliminate the PWB server application 166; in such an implementation all user 
interaction would be provided by the web browser 168. Because communications 
between the server 100 and clients 150 adhere to web standards and the key 
components of the present invention (i.e., the PMB server application 114 and PMB 

30 client applications 166, described below) are compatible with standard web software 
(i.e. f the web s rv r 1 16 and browser 168), the present invention can be 
implemented in any web based client server environment. Moreover, with slight 
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modification, the server and client applications 114, 166 could be made compatible 
with any standard client/server communications packages (e.g., Novell, etc.). 

The data include manifestations 172 of the ACTIVE SERVER PAGES (ASP) 120 
5 downloaded by the web browser 168 in response to events or user requests. These 
manifestations (not shown in detail) enable the user to employ and interact with the 
features of the PMB server application, including the following modes: messaging, 
bulletin board, conferencing, chat, and mail. The manifestations are presented by 
the web browser 166 to users as visuals 162 and/or sounds 164 using the user 
10 interface elements 158. 

The present invention is not limited to the described embodiment. In fact, the 
teachings of the present invention are applicable to any combination of current 
and/or future technology similar to that described herein. For just one example, the 
15 database 108 can be implemented using an object-oriented DBMS, flat text files 

stored on a hard disk 104, or other DBMS or non-DBMS solutions. Having generally 
" = "^e^t^a r tHe^ 

108 are now described in reference to FIG. 2. 

20 Referring to FIG. 2, there is shown a block diagram of the database tables 140, 142, 
144, 146, 148 from FIG. 1. The users table 140 holds information pertaining to 
authorized users of the communication board (i.e., the server application 1 14). The 
users table 140 fields include: 



25 



Id 



DisplayName 



Name 



Unique number automatically assigned to each user, 
[primary key] 

Assigned name for user's account. Used to logon with. 
User's name as it appears in the heading of their Comm 



Board. 



30 



SortPrefs 



Password 



To restrict account access by unauthorized users. 
User's sorting preferences - a 3 character code: 
c=chronological, r=reverse chronological, s=subject, 
e=sender 
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ExpiryPref 



Number of days aft r which a message expires and is 
deleted. 



HasNewMail 
Haslnvitation 

HoldAIerts 



Flag is set to true when user has unread mail. 

Flag is set to true when user has been invited to join a 

conference. 

Flag is true if user does not want alerts for new 
messages, etc to interrupt their session. 



The messages table 142 holds information pertaining to individual messages. Each 
10 participant in a message owns an individual message recordr This allows for 
personalized manipulation of a given message. The messages table 142 fields 
include: 

Msgld Unique number assigned automatically to each message, 

[primary key] 

MsgFileName Name of file that contains message body text. 
ThreadLevel Number 1-6 designating message's level in thread. 



15 



Threadld 
Parentld 



Id of corresponding Threads table record. 



20 



25 



30 



Id of message that is above this message in the message 
thread. Value is zero if message is at top of thread. 
Id of message that is below this message in the message 
thread. Value is zero if message is at the bottom of 
thread. 

Year, month, day, hour, minute and second when 
message was sent. 

Name of user that owns this message record (sender or 
recipient). 

User id of message sender. Corresponds to id in Users 
table. 

User name of message sender. 
SenderNameASCI SenderName sort number. 
Recipient User name of message recipient. 

RecipientLIst Complete comma delimit d list of recipients. 
CcList Complete comma delimited list of carbon copy r cipients. 



Childld 

MsgTimeStamp 
MsgRecOwner 
Senderld 
SenderName 
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IsCafbonCopy- 

Subject 
SubJectASCl 

AckDate 

IsRespondedTo 
Status 

-Type 



15 



20 



ExplryDate 

IsForward 
ForwardThreadld 



to - ..,,„ has been responded to. 

Baa is t~e if message has ^ 

re ad. repKedTo. acked, store ^ 

Typ e rf message contains « - *£ tog Athrea d 
louncemen, invitation, o^^cr^^ 

^^^mr^senttoaituse^ 
announcement is a s.mp g ^ ^ 

default, ^nouncements do r .* ^ ^ ^ t0 

■j^^•- ,I ^ A,og,, " 

^etereco^a,^ 
Date messages to be expire i 
Flag -,strue«message i sfon W arded. 

W of thread being yarded. 



25 



30 



which can be added 

Threa<Md ipHmaryKeyl 

Thr ad subject 

SUb,eC, , ASC . sort numberfor subject. 
SubJ ctASCl 
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- h that is wh n he is a sender orr cipient 
V^ever a user palpal s in athread - . fon m jn „ 

mr ead participants table 148. Thl8t * ^server application 114 would 

thraadsbysubjeoUoragivenuser. Forexample. 
, QamersuchWo^onforapar^laruse * , 148to)ind Readies 

„ issuing a query in the ThreadPa P ^ AaA ln; 

respective threads; and SubjectASCl 

• 



the user. 



16 ^ts^^^^* - 

(primary Key) 

Thread.Dlcorrelatedvflththreadsubject). 
{^rtd ,0 of userv*o is thread participant 

M ^«^*1••--^* ,4 ' , *"* ,,MLl, " 

conference. [Primary key] 
. *a User id of conference moderator. 
25 "T ^orassignedU.pic.orcont.ence. 

^.e of eon.e.nce confine one ofmesevaiuas: pnva^. 

Type ,yp 

asoppos d [to?] immediately. 
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Tim of conference if the conference is scheduled for a 
later time. 



Referring to FIG. 3A, there is shown a data flow diagram illustrating the 
5 relationships between a client application 166 and web browser 168, the web server 
1 16 the server application 1 14 and the PMB databases 108 when a user is send.ng 
a message. The progression of operations shown in FIG. 3 is preceded by a SEND 
request issued by a user that is relayed via the user's web browser 168 to the 
sender application 114 via the web server 116. The sender application 114 in 
10 response returns a manifestation of a SEND page, which the web browser 168 
displays as a SEND page visual 162. The user then completes at least a subset of 
the fields of the SEND page, which include: TO (i.e., one or more recipients), FROM 
(i.e.. sender name), SUBJECT (i.e., message subject) and MSG (i.e., message text). 
It is assumed for this example that the message being sent is a level one message 
1 5 that starts a new thread of conversation. 



20 



The progression shown in FIG 3A. begins when the user sends the message by 
selecting the displayed SEND button on the visual (3.1). In response to the 
selection of the SEND button (3.1) the web browser 168 (possibly with some 
intervention of the client application 1 66) issues an HTTP message transferring the 
SEND data to the web server 116. In accordance with the HTTP (hypertext transfer 
protocol) the browser 168 transmits the SEND data to the web server 116 (3.2). The 
message (3.2) includes the URL of the page for which the data is being transmitted 
(i.e., "SendMsg") and the encoded data. Upon receiving the message (3.2) the web 
25 server 116 decodes, re-packages, and transmits (3.3) the data to the server 
application 114. 

Upon receiving the message (3.3), the server application 1 1 4 performs the following 

operations (3.4-3.14): 
30 3.4) Determines from the users table 140 the IDs of sender and 

recipi nt(s). 

3.5) Writes the MsgTxt to the hard disk (3.5) as a message file 1 36 and 
generat s a corresponding file name (MsgFileName). 
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3.6) Generates a unique ID (MsgID) and sortabl subject number 
( SubjectASCI) for the message. 

3.7) Allocates in the messages table 142 2N message records 143, N for 
the sender 1 43s and 1 for each of the N recipients 143ri (where i is an 
integer between 1 and N); 

3.8) Updates each message record in accordance with the message data 
(only selected field are shown): 

MsgID = message ID generated by server app. 114; 
MsgFileName = message name generated by server app. 114; 
ThreadLevel = 1 (message is at the top of a thread); 
ParentID = 0 (message is at the top of-e thread); 
Childld = 0 (message is also at the bottom of a thread); 
MsgRecOwner = name of a respective one of the participants 
SenderlD - ID of sender; 
1 5 SenderName = user name of sender; 

Recipient = user name of a respective one of the N recipients; 
Recpientlist = list of N recipients; 
Subject = subject completed by sender, 
SubjectASCI = subject sort number generated by server app. 
2 0 AckDate = 0 (message not yet responded to); 

Status = unread (message not yet received); 
Type = thread (message is part of a thread); 
3.9) Generates a unique thread ID (ThreadID) for the thread started by the 
message. 

25 3.10) Allocates a single record 147 in the threads table 146; 

3.11) Updates the thread table record: 

ThreadID = thread ID generated by server app. 114; 
Subject = subject completed by sender; 
SubjectASCI = sort number for subject generated in step; 
30 3.12) Generates a participant ID (ParticipantID) for each participant (1 for 

sender and 1 for each of the N recipients); 
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3.13) Allocat s in the ThreadParticipants Table 148 N+1 records 149, ne 
for the sender 149s end N for each of the N recipients 149ri (wh re i is 
an integer between 1 and N); 

3.1 4) Updates each ThreadParticipant record 149 as follows: 

5 ParticipantID ■ participant ID generated by server app. 1 14 

ThreadID = thread ID generated by server app. 114 
UserlD = message name generated by server app. 114 
ThreadLevel = 1 (message is at the top of a thread); 

1 0 - Referring to FIG. 3B, there is shown an example of how, as a result of the send 
processing performed by the server application 114, multiple records of the 
respective tables are generated and cross-referenced. FIG. 3B assumes a simple 
example where a user with username AmieS has sent a message to two co-workers, 
BobB and SueG. Information for these users is provided in the users table 140, 
1 5 which shows UserlDs (U007. U01 9, U027) and DisplayNames (Arnie, Robert, 

SueEllen) for ArnieS, BobB and SueG, respectively. Upon receiving the message 
the server application 114 creates four new messageTecdrds M001-M004 in the 
messages table 142. Two messages (Msgld=M001 , Msgld=M002) list ArnieS as 
MsgRecOwnen one of these has BobB as Recipient and the other has SueG as 
20 Recipient. The other two messages (Msgld=M003, Msgld=M004) are similar, but list 
BobB and SueG as respective MsgRecOwners. Multiple messages are created so 
each participant (sender or recipient) can independently manipulate their own 
messages. For the same message, a single new Threads table 1 46 record has 
been allocated (Threadld = T001). This single record is associated with all 
25 messages having the same subject (i.e., "The Lee Account") and a corresponding 
unique index (S050). This same ThreadID is associated, for example, with any reply 
by any of the recipients of the original message as well as any subsequent replies 
by the original sender. The server application also allocates 3 thread participant 
records (with Participantlds = P021, 025, 032), one each for ArnieS, BobS and 
30 SueG. These participant records map the participants to their respective userlDs 
(U007, U019, U027) and to the new thread record (Thr adld = T001) associated 
with the subject common to all messages. 
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Referring to FIG. 4A, there is shown a data flow diagram illustrating steps p rformed 
by the web browser 168-1 of a message sender, the server application 1 14 and the 
~web~browser 168-2i5f alnessagerecipientfo 

steps illustrated in FIG 4A occur after the user of the client 150-1 has sent a 
message (4.1) designating a user of the client 150-2 as recipient and the server 
application 114 has processed that message as described in reference to FIG. 3A. 
As part of the processing described in reference to FIG. 3A the server application 
114 determines the recipient(s) of the message (4.2). The server 114 then 
determines whether the recipient(s) is/are on the system (4.3). If the recipient is on 
the system, the server application 114 sends a message-alert (MsgAlert) to the 
recipient (4.4). The MsgAlert (4.4) notifies the intended recipient that a first level 
message is waiting for him. The recipient application/browser 166-2/168-2 displays 
the alert in an alert window (4.5) that gives the recipient two response alternatives: 
OK or CANCEL (4.6). The recipient selects OK to indicate to the server application 
114 that he wishes to receive the message. He selects CANCEL to indicate that he 
does not wish to receive the message and does not want to receive further alerts. 
The recipient can also choose not to respond to the alert at all. This commonly 
occurs when the recipient is away from his computer. 

After sending the MsgAlert (4.1 ) the server application 1 14 waits (4.7) for the 
recipient's response. If the response is NULL, (meaning that the recipient did not 
respond for some predetermined time interval; e.g., 90 seconds) the server 
application 114 resends the MsgAlert (4.8a). 

If the response is OK, the server application sends the Message (4.8b) and updates 
the messages table 142 to show that the message has been posted. This update 
involves changing the status 260 of the messages table records 230 for the sender 
and recipient of the message from "unread" to "read* 230. The server application 
1 14 also sends at the same time any other messages which were in abeyance at the 
server 100 (i.e., messages previously sent but not OKed for delivery by the 
recipient). The status of each of th s messages is also updat d accordingly by th 
serv r application 114. The recipient application/browser 166-2, 168-2 then 
displays the messages in an open, threaded communication board format that is a 
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k yf atur ofthepres nt invention. This display format is described b low in 
refer nee to FIG. 4B. A unique aspect of th described sequence of operations is 
that a user is able to view their communication board messages instantly (that is, as 
soon as they issue an OK), without first needing to log on to a centralized bulletin 
5 board system. Another advantage of the present invention is that the messages are 
displayed with full threading, which is not possible with conventional instant 
messaging systems. 

If the response is CANCEL, the server application 114 places the message in 
10 abeyance (i.e., does not send it) and sends another message to the 
application/browser 166-2, 168-2 causing a message indication to be 
displayed/played on the client user interface 158. For example, the message 
indication could be an alert light or a sound indication, among many other 
possibilities. 

15 

Referring to FIG. 4B, there is shown an image of a communication board format 400 
employed by the present invention to display for asingle user the contents and 
status of conversational threads (e.g., 460, 462, 464, 466) in which that single user 
has participated. This image is displayed as a visual 162 on the user's client 

20 computer by the application/browser 1 66-2/1 68-2 based on inputs received from the 
server application 114. The communication board 400 displays all messages and 
threads owned by a user regardless of subject These messages are displayed until 
they are deleted by a participant, they expire, some event occurs that triggers their 
automatic deletion, or the system administrator deletes them. In addition to 

25 messages (including forwarded and carbon copy (cc) messages), the 

communication board 400 displays announcements broadcast to multiple users and 
conference notifications. 

The communication board 400 lists for each message information from a 
30 corresponding messages record, including its MsgTimeStamp 242, Recipient 246, 
SenderName 245, CcList 250, Subject 254 and MsgT xt. In the illustrat d 
embodiment the MsgTimeStamp 242, Recipient 246, SenderName 245 and CcList 
250 are displayed on the first line 402 of a messag .which is call dth informati n 
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line. The Subject 254 is displayed on th second lin 404 and th MsgT xt 406 is 
displayed n subsequ nt lines. 



In a preferred embodiment, the communication board display is private, meaning 
5 that each user can view only their messages (i.e., messages for which a user is 
listed as MsgOwner in the messages table 142). The present invention is able to 
support this private treatment of messages as it allocates for each one-to-one 
communication two message records 230, one owned by the Sender and one by the 
Recipient A unique feature of the present invention is that messages and replies 
10 thereto appear simultaneously on the communication boards of both the sender and 
the recipient. 

The client displays the messages with full threading information. That is, first level 
messages 442 are displayed with no indentation and lower level messages (i.e., 

15 replies 444 and replies to replies 446) are displayed with corresponding levels of 
indentation. The information necessary to maintain message threading is provided 
by the server application 114 from the Parent, Child, ThreadLevel and Threadld 
fields 238, 240, 236, 237 of the messages table 142. In particular, each displayed 
thread comprises a first level message and its children (family of replies). Note that 

20 many threads can have the same subject (e.g., the threads 460 and 464); however, 
each first level message with the same subject is displayed as a distinct thread. 

To assist user recognition of the different message levels and the status of those 
messages (read, unread, etc.), the displayed embodiment employs color and icons 

25 in addition to indentation. In particular, first level messages are preceded by a 
filled-in square 408, second level messages (replies) are preceded by a filled-in 
diamond 410 and third level messages (replies to replies) are preceded by a filled-in 
circle. In the illustrated embodiment the information line of incoming messages is 
underlined with different colors depending on whether the message has been 

30 responded to (shown in purple) or need to be responded to (shown in blue). 
Alternatively, th information line of all incoming messages can b shown in on 
color (e.g., blue) and with underlining only when the incoming messag has not y t 
been responded to. Not that th se display features (ind ntation, color, icons) are 



WO 99/48011 PCT/US99/06074 

-23- 

not required by the present invention but are niceti s to assist users in navigating 
th open, threaded communication board 400. 



A novel feature of the present invention is message acknowledge (Ack), which 
5 allows a message recipient to agree to/acknowledge a particular message in such a 
way that their agreement/acknowledgment is unambiguously recorded by the server 
application 114. In the displayed embodiment the present invention displays an Ack 
field 420 alongside the information line 402 of all second and -third level messages 
that indicates when and how (explicity or implicitly) a messagswas acknowledged. 
10 An Ack field 420 is not displayed next to first level messages-ia the preferred 
embodiment, but this could also be done in alternative embodiments. The 
acknowledge feature is useful in business applications where it can be used to 
memorialize agreement; e.g., to proposals contained in messages. The 
acknowledge feature also serves to inform senders as to whether or not recipients 
1 5 have read their messages. 

When a user acknowledges a message (explicitly or implicitly) the server application 
1 14 displays the date and time of the acknowledgment on both the sender and the 
recipient's communication boards 400. Explicit selection results in the closing of a 
20 thread, meaning that no more replies on that particular thread are possible and that 
subsequent conversations on the same subject would require a new first level 
message. In the displayed embodiment the Ack field of closed threads are 
underlined with a characteristic color (e.g., red) on the communication boards of 
both participants (e.g., see the Ack field 420-1). 

25 

A user can implicitly acknowledge a received message by replying to that message 
(e.g. by sending a third level message). In this case the server application 114 fills 
in the Ack line 420 of the second level message with the date and time the third 
level message was sent When such a reply is sent the server application 114 does 
30 not close the thread as the reply merits its own acknowledgement. As a result, the 
server application 114 does not display th Ack field 420 with th characteristic 
color of a closed thr ad (e.g., see th Ack field 420-2). 
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Ifth recipient of a second or third message has not repli d or acknowledged to 
such a message, th Ack field 420 is left blank on the sender's communicati n 
board 400 (e.g., see the Ack field 420-3). therefore, at fail times sendens^leTo"" 
determine the current status of their outgoing messages without needing to login to 
5 another service - i.e., the status is displayed through the visual cues presented on 
the communication board screen 400. 

In the preferred embodiment, information lines 402 for incoming messages have a 
hyperlink function such that selecting the underlined portion of the information line 
10 causes the application serveM 14 to return a reply screen/visual 162 that is partially 
filled out with the appropriate Recipient, Sender and Subject. The message reply 
procedures implemented in the present invention are described below, in reference 
to FIG. 5. There is no hyperlink function associated with the information lines of the 
outgoing messages. 

15 

As an example of these features, refer to FIG. 4B, which shows the communication 
— ~board 400 for the user, "Mif. T^ncommunication board 400 shows Mit has 9 

current messages and 4 open messages, which are messages that have not been 
closed/acknowledged). The underlined message headers are associated with 
20 replies to Mit and the plainly-displayed message headers are associated with 

messages sent by Mit This example includes four threads 460, 462, 464, 466. The 
thread 460 comprises two messages of the following levels: 
level 1 msg 442, to Arlene from Mit; and 
level 2 reply 444 to the level 1 msg; 

25 

Each message is displayed in open format, meaning that its text can be read without 
selecting/opening the message. For example the first level message 442 has the 
following openly displayed MsgText: 

"Pis order 3R report on 145 Piccadilly and give copy to Agnes." 

30 

The message 442 was responded to by Arlen , whose reply 444 includes the 
following MsgText 

tt 3R report ordered. Will give copy to Agnes. p 
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ln response to Arl ne's 444, which cl ariy closed out the conv rsation, Mit sent an 
explicit acknowl dgement that caused the server application 1 14 to close the thread 
460. Thus, the Ack field 420-1 of the message 444 is shown underlined, indicating 
thread closure. 

5 

Due to the symmetry with which the message records are created (i.e. two message 
records created per communication pair), similar message information is displayed 
in real time on the communication boards of all participants to a thread; For 
example, referring to FIG. 4C, there is shown a portion of Arlene's communication 

1 0 board 400A listing some of the same threads 460, 462 as Mit's board 400*- In 
particular, Arlene's thread 460A and messages 442A, 444A correspond to Mit's 
thread 460 and messages 442, 444. Note that, on both boards 400 and 400A, the 
Ack information 420-1 for the corresponding messages 444 and 444A is identical. 
However, the information lines of the messages 444 and 444A differ. That is, on 

1 5 Mit's board, the information line of the message 444 (from Arlene to Mit) is 
underlined but, on Arlene's board, the corresponding information line is not 
underlined. This because Arlene was the sendeTofthis message. Other" 
differences between Arlene's and Mit's boards are due to the fact that Arlene and 
MH participate in different threads with different users. 

20 

A user can choose an alternative view of their messages by using the message 
review board feature of the present invention. A message review board presents a 
view of all messages in the user's message folder (i.e., stored messages) with a 
common subject For example, referring to FIG. 4D, which shows a message review 

25 board 1400, the threaded, instant messages shown are all associated with the same 
subject 1404 ("145 Piccadilly") and are owned by the user, "Mit". The message 
review board presents the messages in the same manner as a communication 
board. The underlined message headers are associated with replies to Mit and the 
plainly-displayed message headers are associated with messages sent by MiLThe 

30 example of FIG. 4D includes three threads 1440, 1460, 1480. The thread 1440 
comprises three messages of th following I vels: 
level 1 msg 1442, to Arlene from Mit 
level 2 reply 1444 to the level 1 msg; and 
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a level 3 reply 1 446 to the level 2 reply; 



Each message is displayed in open format, meaning that its text can be read without 
selecting/opening the message. For example the first level message 1442 has the 
following openly displayed MsgText: 

"Where are the signed copies of the TDS and Supp TDS? I need to provided 

copies to the lender." 



The message 1442 was responded to-by Arlene, whose reply 1444 is displayed on 
10 Mit's message review board 1400. Arlene's reply 1444 includes the following 
MsgText: 

"Buyer's agents will be dropping off signed copies tmo. I will go ahead and 
give copies of same to the Lender when I get them back." 

15 Mit replied to the reply 1444 with another reply 1446: 

"Thanks a whole lot That will save me a lot of time. I owe you one!" 



By sending this reply 1446 Mit implicitly acknowledged the reply 1444 from Arlene. 
Consequently, the thread 1440 is still open and the server application 114 sets the 
20 date and time of the acknowledgment 1420-1 to the date and time {10-04-97 16:14) 
Mit sent the reply 1 446. 

In response to the reply 1446, which clearly closed out the conversation, Arlene 
sent an explicit acknowledgement that caused the server application 1 14 to close 
25 out the thread. Thus, the Ack field 1420-2 of the message 1446 is shown 
underlined, indicating thread closure. 

The preceding description is directed to an embodiment of the present invention 
where the communication boards are private and provide instant, open display of 
30 threaded messages. Alternative and equally novel embodiments of communication 
syst ms can employ various combinations of these concepts (privacy, instant 
messaging, threading and open display). F r example, the teachings f the pres nt 
invention could be employed in the following novel systems: 



30 
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1 ) public bulletin boards with open display of messages; 

2) -mail systems with open display of messages; 



3) e-mail systems with threading of messages; 

4) private bulletin boards with no other unique features; 
5 5) private bulletin boards with instant messaging; 

6) private buileting boards with instant messaging and open display; and 

7) instant messaging systems with threaded of messages. 

- Descriptions of these embodiments are not provided herein as their respective 
10 implementations should be apparent from the descriptions already provided. Other 
embodiments consistent with these teachings and descriptions will occur to the 
reader skilled in the art and are within the scope of the present invention. Having 
described the communication board concept, the message reply process is now 
described. 

15 

Referring to FIG. 5A, there is shown a data flow diagram illustrating steps performed 
by a web browser 168-1 of a message replier, the server application^ 14, and a web 
browser 168-2 of a message reply recipient for a message reply procedure. The 
steps illustrated in FIG 4A occur after the user of the client 150-2 has received a 

20 message (4. 1 ) from a user of the client 1 50-1 . Upon displaying a message on their 
communication board as described in reference to FIG. 4, a user can choose to 
reply to that message by selecting a reply option from a menu, an icon, or other 
equivalent methods (5.1). Once the user has selected the reply option a reply box is 
displayed (5.2) that allows the user to specify the reply's recipient and subject 

25 (these fields are filled in by default with the sender's information) and MsgText. The 
reply box description could be sent by the server application 1 14 or could be 
generated by the client application 166-1. The user fills in the reply (5.3), and then 
sends it off to the server application (5.4). Key information conveyed to the server 
in the reply includs the Msgld of the message responded to. 



In response, the s rver application 114 assigns a uniqu MsgID to th r ply (5.5), 
generates corresponding message records 230 for the reply s nder and recipi nt 
(5.6) and updates database 108 records accordingly, including setting parent and 
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child pointers to and from other message records 230 (5.7). Th server application 
1 14 then posts its reply to the indicated recipients (e.g., the user of the client 1 50-1 ) 
\F they are online (5.8). NoTe that, unlike first level messages, theserver 
application 1 14 does not issue queries to recipients asking if they would like to a 
5 reply to be sent Instead, the server appliation 114 pushes replies to recipients. 
Morever, every time it pushes one reply, the server application 114 pushes all other 
replies held in abeyance (except for first level messages not yet accepted). An 
illustration of the databases 108 reflecting processing by the server application 114 
in response to a reply is now described in reference to FIG. 5B. 

10 

Referring to FIG. 5B, there is shown an example of how, as a result of the reply 
processing performed by the server application 114, multiple records of the 
respective tables are generated and cross-referenced. FIG. 5B assumes a simple 
example where SueG has responded to the message sent by AmieS (refer to 

15 discussion of FIG. 3B). Upon receiving the reply message the server application 
114 creates two new message records M005, M006 in the messages table 142. one 
One of these messages (Msgld=M005) lists AmieS as MsgRecOwner and Recipient 
and SueG as Sender. The other message (Msgld=M006) is similar, but lists SueG 
as MsgRecOwner and sender and AmieS as Recipient A new Threads table 146 

20 entry has not been allocated as the subject (i.e., "The Lee Account") and subject 
index (S050) for the reply are already represented by the Thread TOOL Nor are 
new ThreadParticpant table 148 entries allocated. This is because the two 
participants in the reply (AmieS and SueG) have appropriate records (with 
Participantlds = P021 and 032) in teh ThreadParticipants table 148. 

25 

Referring to FIG. 6, there is shown a data flow diagram illustrating steps performed 
by the web browser 168-1 of a message acknowledger and the server application 
1 14 for a message acknowledge procedure. The steps illustrated in FIG 4A occur 
after the user of the client 150-2 has received a reply message (5.7) from a user of 
30 the client 150-1 . A user can choose to acknowledge explicity a message displayed 
on their communications board 400 by selecting an Ack option from a menu, icon, or 
other equivalent means (6.1 ). In response, th client appliction/br wser 166-2/166- 
3 relays pertinent information (including Msgld) for the messag b ing explicitly 
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acknowledged to th server application 114 (6.2). Thes rver application 114 
processes the message acknowledgment as described in r f r nee to FIGS. 4A-4C 
and I update^lf^alaba7esl68 accordingly ^aO^plBnyby'^nging the status" 
of the relevant message record to "ACKed" and completing the AckDate 256 (FIG. 
2). The server application 114 then posts the acknowledgement to the respective 
communications boards 400 of both participants (i.e., the sender using the client 
150-1 and the recipient using the client 150-2) as described in reference to FIGS. 
4B-4C (6.4). In a preferred embodiment the acknowledgment is only sent when the 
sender is online. 

Alternatively, as described above, an acknowledgment can be sent implicitly as the 
result of a recipient of other than a first level message responding to that message. 
In this situation the server application 114 allocates new message records 230 in 
the same manner as for a reply (FIG. 5B); i.e., the Status 260 of those records is not 
listed as Acked and the AckDate 256 (FIG. 2) is not filled in. Additionally, the 
IsRespondedTo flag of the parent messages is set. 

An example of the databases 108 resulting from the processing of an 
acknowledgment is not shown given the similarity of these results to those in the 
reply case, already described in reference to FIG. 5B. 

In addition to the communication board features described above, the present 
invention provides additional conference, whisper, talk and mail modes. It is a 
key feature of the present invention that these modes are integrated with the 
communications board features. It is now described reference to FIG. 7 how the 
server application 114 supports conference mode. 

Referring to FIG. 7A, there is shown a flow chart illustrating steps by which the 
server application 114 schedules a conference, notifies conference participants and 
holds the conference. As the first step in scheduling a conference a user/moderator 
b gins conference mode operations (702). The moderator th n schedules a 
conference (704) by defining its: 
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particlpants (one or more users if conference is privat , not necessary when 

conference is pen); 

topic; 

data and time; and 

5 type (open or private), where open means that any user can participate in the 

conference and private means that a user can only participate if invited by the 
moderator. 



This information is entered by the moderator orTST conferences page 162 generated 
10 by a browser 168 from information (typically formatted as ACTIVE SERVER PAGES) 
forwarded by the server application 114. The completed conference page 162 is 
returned to the server application 114, which allocates a new record 270 in the 
conferences table 144 (706). The server application 114 updates the fields (706) of 
the new conference record 270 as follows: 
15 ID set to a unique ID generated by the application 114; 

Moderator set to the user name of the moderator; 

Topic set the topic defined by the user on the conferences 

page 162; 

Type set to type (open or private) selected by the moderator; 

20 Participants set to particpants entered by the moderator; 

IsScheduIed set to 1 if the user indicated that the conference is to be 

scheduled for future as opposed immediately; and 
When date and time entered by moderator. 

Finally, the server application 114 schedules a virtual conference room for the 
25 future, or immediately, depending on when the conference is scheduled (706). 

Depending on when the conference is scheduled, at an appropriate time (which 
could be immediately or sometime in the future) (708-Y) the server application 114 
sends notifications to the conference participants (710). 



30 



As shown in FIG. 7B, which is an image of us r Mit's communication board 720 
including conference notifications and announcements, the notifications are 
displayed similarly to messages (including the possibility of acknowledgements). In 
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particular, op n conference notifications, such as the notifications 722, 728, are 
sent to all users, and privat conference notifications, such as the notifications 746, 
752, and 756, are only sent to invited participants. Referring to an exemplary 
notification 722, all notifications display: 
5 a subject 740 that indicates the type of notification (e.g., PRIVATE 

CONFERENCE NOTIFICATION); 
the virtual conference room 742 (e.g., Room 1258); 
. the date and time 744 of the conference (e.g., NOW); 
the topic 746 (e.g., "Affect of new Health Ins Benefits"); and 
10 -an IN PROGRESS indication 748 if the conference is in progress. 

Note that private conference notifications can be acknowledged in the same manner 
as messages. For example, in response to the notification 732 from Arlene 
regarding a private conference to discuss future Christmas parties, Mit issued a 
1 5 confirming reply 734, which was later acknowledged 750 by Arlene. The 

acknowledgment 750 also closes the thread consisting of the messages 732, 734. 



FIG. 7B shows another feature of the present invention, announcements 724, 730, 
which are immediate messages broadcast to all users who are online. 

20 

Referring again to FIG. 7 A, at the scheduled time the server application 114 hosts 
the conference (714) by: 

allocating the virtual conference room; 

notifying all participants again that the conference is starting (e.g., the IN 
25 PROGRESS notification 722); 

and allowing the moderator to administer the conference in accordance with 
the type of conference (e.g., if the conference is public, users can join at will, 
but if the conference is private, users can only join at if invited by the 
moderator). 

30 

One example of a confer nee session scr en 770 is shown in FIG. 7C. Th sere n 
770 includes an agenda 772 defined by the moderator, a comment sere n 774 on 
which comm nts typed by participants on their own confer nee input scr nsar 
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displayed and a list of participants 776. This screen 770 is displayed for all users 
who are participants in the conference by their respective browsers 168. In a 
preferred embodiment all conference information is logged by the application server 
1 14 on the hard disk 104. The screen 770 includes an ANON button, which, when 
5 selected, allows a user to participate in the conference anonymously. 



A unique feature of the present invention is whisper mode, which is implemented in 
conjunction with conference mode. During a conference two users who wish to 
carry on a private, untagged conversation can enter whisper mode. When in 
10 whisper mode users view their conversation on-awhisper mode screen on which 
only their comments are displayed. No other user can view comments made by 
whisper mode participants. 

Referring to FIG. 8 ( there is shown an exemplary talk session dialog input screen 
15 800 in which a user (e.g., Arlene) enters a talk message 804 she would like to send 
to another user 802 (e.g, Mit) as part of a talk session. In the preferred 
embodiment, a user can start a talk session from any system mode other than 
conference mode. When the user is satisfied with the message 804, they select the 
send button 806, which causes the client application/browser 166, 168 to send the 
20 information from the talk session dialog input screen to the server application 114. 

The server application 114 then determines whether the intended talk session 
participant (e.g., Mit is online). If the intended participant is online, the server 
application 114 sends him a talk mode incoming message box, which announces a 

25 new incoming message and gives the intended participant the option of checking 
the message (i.e., joining in the talk session) or declining to participate. The 
incoming message box is displayed for the intended recipient no matter which mode 
his client 150 is in. If the intended participant declines to talk or is not available, the 
server application 114 sends the requestor (e.g., Arlene) a party not available 

30 message, indicating that the talk session cannot commence. If the intended 

participant is availabl and agrees to join the talk session, th s rver application 
114 causes his client application/browser 166/168 to display the message and gives 
him an opportunity to respond. 
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If the user elects to respond, he enters a message in a response input box and 
causes th appropriat browser 168 to send the information defined ther in to the 
server application 114. The response input box is very similar to the talk session 
dialog input screen 800, shown in FIG. 8 and is therefore not described herein. 
Upon receiving the response, the server application 1 14 resends the first participant 
(e.g., Arlene) a dialog screen showing the second participants response alongside 
the first participant's initial message. From this screen the first participant has the 
opportunity to send a reply back to the second participant. An exemplary talk dialog 
screen 820 for Arlene is shown in FIG. 8B. This screen shows in its upper section 
822 Arlene's initial message 824 and Mit's response 826. The screen 820 also 
includes a response input box 830 in which Arlene can enter a subsequent 
response. The talk session can proceed with screens like the screen 820 until one 
of the users signals an intention to exit the talk mode. 

As an example of the integration provided by the present invention, the server 
application 114 causes a incoming message alert to pop up during talk mode to 
notify a talk mode participant that he has a waiting communication board message. 
The alerted user can choose to check the message or CANCEL the alert, causing 
the server application 1 14 to initiate message processing operations already 
described in reference to FIGS. 4-6. While the user is checking his messages, the 
server application 114 causes the browser 168 used by the other talk session 
participant to display a talk session paused message. The talk session is re- 
activated when the participant checking his messages chooses to rejoin the talk 
session. 

Talk session information is centrally maintained - in this case in a talk table 850 
(stored in the database 108). Unlike most other modes (except for whisper mode), 
talk messages are not logged on the hard disk 104 server; therefore, the talk table 
850 only includes a small set of status information for each talk session. In a 
preferred embodiment this status information includes: 

TalkSessID Unique key for each talk session gen rated by the 

serv n 

FirstParflcipant First participant user name; 
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ScndParticipant Second participant user name; 

InActive Set to indicate that one of participants has n ot yet agr ed 

to join session; 

MessageFIg Set to indicate that one of the participants has paused 

session to check a new message; 
MessageTS Date and time when participant paused session to check 

new message. 



The server application 114 allocates a single talk record for each new talk session. 
10 There is no need for the server application 114 to keep track of individual responses 
as talk sessions are not logged in the preferred embodiment. 

Another mode offered by the present invention is mail mode. Unlike conventional e- 
mail programs, in its mail mode the present invention is able to provide threaded 
15 mail over the Internet. An example of a mail screen 900 displayed for a particular 
user is shown in FIG. 9. 



The mail screen 900 lists mail received 902 and sent 904 by a particular user (e.g., 
Mit). Each incoming e-mail message is treated by the server application 1 14 as a 
20 level one message that begins a respective e-mail thread. Replies to the incoming 
e-mail messages are indented on the mail screen 900, visually indicating their 
position as second level messages in their associated thread. For example, the 
incoming e-mail messages 906, 908 and 910 all have replies 906a, 908b, 910c. 

25 Each of the incoming messages has a subject line (e.g., the subject 912 of the 
message 906) that is underlined. When a user selects the underlined subject line 
he prompts the server application 1 14 to return to the user's client 
application/browser 166/168 an e-mail reply box with most fields (such as sender, 
recipient, subject, date and time) already filled-in. The user then fills in the message 

30 text and sends the e-mail message. As with the other modes, after a reply is sent 
th mail screen 902 is immediately updated by the server application 114 with th 
threading information. Outgoing mail is handled in the same manner xcept for the 
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problem that threading information may not be maintain d by xternal e-mail s rvers 
that receiv the outgoing messages. 



As with the other system modes, e-mail information is centrally maintained - in this 
case in a mail table 920 (stored in the database 108) whose fields include: 



MaillD 

MailTimfcSlamp 

Sender 

SenderAdr 

Recipient"" 

RecipientAdr 

Threadld 

ThreadLevei 

Subject 



MsgFN 



Unique key for each email message generated by the 
server; 

Date and time message was sent or received; 

Sender Name; 

Sender e-mail address; 

Recipient Name; 

Recipient e-mail address; 

Unique Id for each mail Thread; 

Top level messages have level = 1, 

Replies have level = 2; 

Message subject; and 

Name of file on hard disk 104 where MsgText is stored. 



The server application 114 allocates a mail message record for each new e-mail 
(outgoing, incoming, or reply) and updates these e-mail fields in much the same way 
as in the message situation described above. As a result, the processing of e-mail 
messages by the present invention is not further described. 



While the present invention has been described with reference to a few specific 
embodiments, the description is illustrative of the invention and is not to be 
construed as limiting the invention. Various modifications may occur to those skilled 
in the art without departing from the true spirit and scope of the invention as defined 
by the appended claims. 
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1 . A system for threaded instant messaging for use in a network of computers 
including a server computer, comprising: 

5 a server mechanism executable in the server configured to make instantly 

available to a user who is logged onto the server representations of messages sent 
to the user and to maintain threading information associated with the messages; 

the server mechanism also being configured to display-the representations of 
messages to the user along with a representation of the threading information. 

10 

2. The system of claim 1 , wherein the server mechanism^ configured to display 
the representations in an open format wherein the messages do not need to be 
selected to be read. 

15 3. The system of claim 1 , wherein the server mechanism is configured to display 
the representations on a private message board that only shows communications 
sent to and by the user and which can be viewed only by the user. 

4. The system of claim 3, wherein the server is configured to maintain a plurality 
20 of private message boards, one for each user of the system; such that, whenever a 

representation of the message is displayed on the private message board of one 
participant in the message, a corresponding representation of the message is 
displayed nearly simultaneously on the private message board of another 
participant in the message. 

25 

5. The system of claim 1 , wherein the server mechanism is configured to enable 
users to acknowledge messages; such that, when the user acknowledges a 
particular message, the server mechanism notifies a second user who is a 
participant in the message of the user's acknowledgment of the particular message. 

30 

6. The system of claim 5, wherein the acknowledgment can be explicit or 
implicit, such that 
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when the acknowledgment is explicit, th server mechanism closes a thread 
including the particular message; and 

v/ ^ en the aC k now | e dgment is implicit, the server mechanism leaves open the 
thread including the particular message, the implicit acknowledgment occurring 
5 whenever the user replies to the particular message. 

7. The system of claim 6, wherein the explicit acknowledgment is employed by 
the user to manifest acceptance of/agreement to contents of the message. 

10 8. The system of claim .1 , wherein the server mechanism is configured to queue 
at the server at least a subset of the messages addressed to the user without 
displaying to the user the representations of the subset until the user has approved 
transmission of at least one of the messages in the subset, after which the server 
mechanism displays the representations of the subset to the user. 

15 

9. The system of claim 1 , wherein the server mechanism displays the 
representation of the message along with a hyperlink field, the selection of which by 
the user causes the server mechanism to display to the user a reply window with at 
least some fields filled out with information associated with the hypertext field, 

20 enabling the user to formulate a reply to the sender of the message. 

10. The system of claim 1 , further comprising: 

a message table including message records, each of which is associated with 
a message having a sender, recipient, owner and subject; 

25 such that, whenever the user sends a message to N other users, the server 

mechanism allocates 2 x N message records, N of which have respective ones of 
the other users as the owner and the other N of which have the user as the owner, 
all of the 2 x N messages having the same sender and subject, respective pairs of 
the 2 x N messages listing as the recipient a respective one of the other users; 

30 the server mechanism being additionally configured to display for each of the 

N + 1 users only those messag for which he is owner. 
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1 1 . The system of claim 1 0, wherein the server mechanism enabl s ach of th 
users to manipulate only thos messages for which he is the owner. 



12. The system of claim 11, wherein messages with the same subject, sender, 
5 recipient and message text are displayed nearly simultaneously to the respective 

owners of the messages. 

13. A system for open display bulletin boards for use in arretwork of computers 
including a server computer, comprising: 

10 a server mechanism executable in the server configured to provide a bulletin 

board system wherein messages submitted to the bulletin board by users of the 
network are displayed with threading information and in an open format wherein all 
messages are displayed in full and do not require prior selection for viewing. 

15 14. The system of claim 13 wherein the server mechanism is configured to 
. display the messages on a plurality of private message boards, each of which only 
shows communications sent to^ncJ by a respective user and which can be viewed 
only by the respective user. 

20 15. The system of claim 14, wherein, whenever a first representation of a 

particular message is displayed on the private message board of one participant in 
the particular message, a corresponding representation of the particular message is 
displayed nearly simultaneously on the private message board of another 
participant in the particular message. 

25 

16. The system of claim 13, wherein the server mechanism is configured to 
enable users to acknowledge messages; such that, when the user acknowledges a 
particular message, the server mechanism notifies a second user who is a 
participant in the particular message of the user's acknowledgment of the particular 
30 message. 



17. The syst m of claim 16, wherein the acknowledgment can b xplicit or 
implicit, such that: 
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when the acknowledgment is explicit, the s rver mechanism closes a thread 
including the particular m ssage; and 

when the acknowledgment is implicit, the server mechanism leaves open the 
thread including the particular message, the implicit acknowledgment occurring 
5 whenever the user replies to the particular message. 

1 8. The system of claim 1 7, wherein the explicit acknowledgment is employed by 
the user to manifest acceptance of/agreement to contents of the particular message. 

10 19. The system of claim-1 3, wherein the server mechanism is configured to 

queue at the server at least-a subset of the messages addressed to the user without 
displaying the representations of the subset until the user has approved 
transmission, after which the server mechanism displays the representations of the 
subset to the user. 

15 

20. The system of claim 13, wherein the server mechanism displays the 
repremrttation^ 

the user causes the server mechanism to display to the user a reply window with at 
least some fields filled out with information associated with the hypertext field, 
20 enabling the user to formulate a reply to the sender of the message. 

21 . The system of claim 1 3, further comprising: 

a message table including message records, each of which is associated with 
a message having a sender, recipient, owner and subject; 

25 such that, whenever the user sends a message to N other users, the server 

mechanism allocates 2 x N message records, N of which have respective ones of 
the other users as the owner and the other N of which have the user as the owner, 
all of the 2 x N messages having the same sender and subject, respective pairs of 
the 2 x N messages listing as the recipient a respective one of the other users; 

30 the server mechanism being additionally configured to display for each of the 

N + 1 users only those message for which he is owner. 
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22. The system of claim 21 , wherein the server mechanism nabl s each of the 
users to manipulat only messages of which he is the owner. 



23. The system of claim 22, wherein messages with the same subject, sender, 
5 recipient and message text are displayed nearly simultaneously to the respective 

owners of the messages. 

24. A private message board system for use in a network of-computers including 
a server computer, comprising: 

10 a server mechanism executable in the server configured to provide a plurality 

of private bulletin boards for each of a plurality of users of the -system, wherein each 
of said private bulletin boards shows history of messages associated with 
conversations involving a respective user. 

15 25. The system of claim 24, wherein the server mechanism is configured to 
display representations of the messages in an open format wherein the messages 
do not need to be selected to be read: 

26. The system of claim 24, wherein the server mechanism is configured to 
20 display nearly simultaneously with its posting a particular message on the private 

message boards of all participants in the message. 

27. The system of claim 24, wherein the server mechanism is configured to 
enable users to acknowledge messages; such that, when the user acknowledges a 

25 particular message, the server mechanism notifies a second user who is a 

participant in a thread containing the thread of the user's acknowledgment of the 
particular message. 

28. The system of claim 27, wherein the acknowledgment can be explicit or 
30 implicit, such that: 

when the acknowledgment is xplicit, the server m chanism closes the thread 
including the particular message; and 
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when the acknowledgment is implicit, the server mechanism leaves open the 
thread including th particular message, the implicit acknowledgment occurring 
whenever the user replies to the particular message. 

5 29. The system of claim 24, wherein the server mechanism is configured to 

queue at the server at least a subset of the messages addressed to the user without 
displaying the representations of the subset until the user has approved 
transmission, after which the server mechanism displays the representations of the 
subset to the user. 

10 

30. The system of claim 24, wherein the server mechanism displays a 
representation of the message along with a hyperlink field, the selection of which by 
the user causes the server mechanism to display to the user a reply window with at 
least some fields filled out with information associated with the hypertext field, 
15 enabling the user to formulate a reply to the sender of the message. 

^l7~"~Th~e^ste7T^ comprising: 

a message table including message records, each of which is associated with 
a message having a sender, recipient, owner and subject; 
20 such that, whenever the user sends a message to N other users, the server 

mechanism allocates 2 x N message records, N of which have respective ones of 
the other users as the owner and the other N of which have the user as the owner, 
all of the 2 x N messages having the same sender and subject, respective pairs of 
the 2 x N messages listing as the recipient a respective one of the other users. 

25 

32. The system of claim 31 , wherein messages with the same subject, sender, 
recipient and message text are displayed nearly simultaneously on the private 
message boards of the respective owners of the messages. 



30 



33. A communication board system for use in a computer network including a 
s rver, comprising: 

a server application executable on the s rv r; and 
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a client application providing an interface between system users and th 
server application; 

such that said client application and server application are configured 
cooperatively to provide each of said users with a respective view of a virtual 
5 bulletin board system illustrating history and content of at least a subset of said 
messages, said respective view being instantly accessible to and customizable for a 
corresponding one of said users. 

34. The communication board system of claim 33, wherein the server application 
10 and the client application are browser-based, enabling the communication board 

system to be implemented on any computer network compatible-with Internet-based 
protocols. 

35. The communication board system of claim 34, wherein the computer network 
15 is selected from: 

the Internet; 

— anintranetror 

an extranet 



20 36. The communication board system of claim 33, wherein said respective view 
includes only those of said messages associated with conversations to which said 
corresponding user is a participant 

37. The communication board system of claim 33, further comprising: 

25 a data repository in which the server application stores information about 

system users and messages exchanged between said users. 

38. The communication board system of claim 37, wherein the data repository 
comprises: 

30 a message table including message records, each of which is associated with 

a message having a sender, recipi nt, owner, subject and thread id; 

such that, whenever a user sends a message to N oth r users, the server 
application allocat s a message family of 2 x N message r cords, N of which have 
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respective ones of the other users as the owner and the other N of which hav the 
first user as the owner, all of the 2 x N messages having th same send r, subject 
and thread id, respective pairs of the 2 x N messages listing as the recipient a 
respective one of the other users, the sending user and other users being thread 
5 participants. 

39. The communication board system of claim 36, wherein messages with 
identical subject, sender, recipient and thread id can be provided nearly 
simultaneously on the respective views provided to the respective owners of the 

10 messages. 

40. The communication board system of claim 38, wherein, when a first user 
sends a first level message to a second set of users using the client application, the 
server application is configured in response to: 

15 allocate the family (first level family) of message records for the first level 

message; 

generate aunique threadid^ndassociate the unique thread id with each of 

the first level family; 

update each member of the first level family with the sender, recipient, owner 
20 and subject information for a respective thread participant; 

issue a message alert to the client applications of each of the other users; 
transmit a representation of a respective message record to the client 
application of each of the second set of users who agrees to delivery of the 
message; and 

25 hold in abeyance transmission of a representation of a respective message 

record to each of the second set of users who does not agree to delivery of the 
message. 

41. The system of claim 40, wherein, when a third user sends a reply to a 

30 message from a fourth user using the client application, the server application is 
configured in respons to: 

allocate the family (reply family) of message records for the reply message; 
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associate the unique thread id from a parent family with each member of the 
reply family, the par nt family being the message records associated with the 

message from the fourth us n — — - 

update each member of the reply family with the sender, recipient, owner and 
5 subject information for a respective participant in the reply message; 

link members of the reply family with related message records of the parent 
family; and 

transmit a representation of a respective reply message record to the client 
application of the fourth user. 

10 

42. The communication system of claim 41 , wherein, when a third user explicitly 
acknowledges an incoming message using the client application, the server 
application is configured in response to: 

update the message records associated with the thread that includes the 
1 5 incoming message to show that the thread is closed; 

transmit a representation of the incoming message to the client applications 
of participants in t he thread that includes the incoming message conveying that the 
thread is closed. 

43. The communication system of claim 41 , wherein, when a third user implicitly 
20 acknowledges an incoming message using the client application, the server 

application is configured in response to: 

update the message records associated with the thread that includes the 
incoming message to show that the thread is responded to; 

transmit a representation of the incoming message to the client applications 
25 of participants in the thread that includes the incoming message conveying that the 
thread is responded to. 

44. The communication board system of claim 36, wherein the respective views 
display representations of the messages in an open format wherein the content of 

30 the messages can be read without selecting the messages. 



45. The communication board system of claim 36, wherein the respective views 
display the repres ntation of a message along with a hyperlink field, th selection of 
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which by the user causes the server and client applications cooperatively to display 
to the user a reply window with at least som fields filled out with informati n 
associated with the hypertext field, enabling the user to formulate a reply to the 
message. 

5 

46. A method for threaded instant messaging for use in a computer network, 
comprising the steps of. 

displaying messages sent over the network involving a user of the network so 
that only said user can view messages sent and received by said user; 
10 displaying said messages in an open format so that content of said messages 

is viewable without selection; 'and 

immediately making said messages available for viewing by said user 
whenever said user is online. 

1 5 47. The method of claim 46, further comprising the steps of: 
maintain threading information of said messages; and 

displaying-a^representation-of saidihreading information along with said 

messages. 

20 48. The method of claim 46, further comprising the steps of: 

whenever a user sends a message to N other users, allocating a message 
family of 2 x N message records, N of which have respective ones of the other users 
as the owner and the other N of which have the first user as the owner, all of the 2 x 
N messages having the same sender, subject and thread id, respective pairs of the 

25 2 x N messages listing as the recipient a respective one of the other users, the 
sending user and other users being thread participants. 

49. The communication board system of claim 48, further comprising the steps of: 
when a first user sends a first level message to a second set of users: 
30 allocating the family (first level family) of message records for the first 

level message; 

generating a unique thread id and associat th unique thread id with 
each of the first lev I family; 
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updating each member of the first lev I family with the sender, 
recipient, owner and subject information for a respective thr ad participant; 
jssujn g a messa g 0 B \ er x \ 0 eac ^ 0 f the other users; 

transmitting a representation of a respective message record to each 
5 of the second set of users who agrees to delivery of the message; and 

holding in abeyance transmission of a representation of a respective 
message record to each of the second set of users who does not agree to delivery 
of the message. 

10 50. The method of claim 49, further comprising the sleps of: 

when a third user sends a reply to a message from a fourth user, 

allocating the family (reply family) of message records for the reply 

message; 

associating the unique thread id from a parent family with each 
15 member of the reply family, the parent family being the message records associated 
with the message from the fourth user; 

updating eachmemberofthereplyfamilywit^^^^ 
owner and subject information for a respective participant in the reply message; 

linking members of the reply family with related message records of 
20 the parent family; and 

transmitting a representation of a respective reply message record to 
the fourth user. 

51 . The method of claim 50, further comprising the steps of: 

25 when a third user explicitly acknowledges an incoming message, 

updating the message records associated with the thread that includes 
the incoming message to show that the thread is closed; and 

transmitting a representation of the incoming message to participants 
in the thread that includes the incoming message conveying that the thread is 
30 closed. 

52. The method of claim 50, further comprising the steps of: 

when a third user implicitly acknowledges an incoming message, 
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updating the message records associated with the thr ad that includes 
the incoming messag to show that the thread is res ponded to; and 

transmitting a representation of the incoming message to the client 
applications of participants in the thread that includes the incoming message 
5 conveying that the thread is responded to. 

53. A system for memorializing agreement for use in conversations and 
negotiations conducted via an electronic communication system, comprising: 

a server program that opens a thread corresponding to each conversation 
10 ongoing in the communication system; 

a data repository in which the server program records status and content of 
messages composing said conversation; and 

a client program configured to cooperate with said server program to enable 
users of the electronic communication system to view and respond to said 
15 messages; 

a user response including acknowledgment, wherein a user signifies 
agreement toa particular messageDy~acKnowledging sard-particutarmessage, said 
client program being configured to relay said acknowledgment to said server 
program, which is configured to close said particular message's thread and update 
20 said data repository to show said status of said particular message is 
acknowledged. 

54. A threaded e-mail system for use in a computer network, comprising: 

a server application running in a server attached to the computer network; 
25 an e-mail database; 

a client application employed by users to interact with the server application 
to perform e-mail operations, including exchanging e-mail with external 
correspondents and viewing e-mail messages and e-mail status; 

the server application being configured to allocate a first new record in the e- 
30 mail database corresponding to each new incoming e-mail and to associate each of 
the first new records with a uniqu -mail thread id; 

the server application b ing configured to allocat a second new record in 
the e-mail database corresponding to ach reply to the incoming e-mail and to 
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associate achofthes condnewr cords with the unique e-mail thread id of th 
incoming -mail repli d to; and 

the server application being configured to present information to the client 
application from the e-mail database enabling the client to display the e-mail 
5 messages and e-mail status including threading information showing common 

subject matter and history of the incoming e-mail and the replies thereto issued by a 
respective user. 
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Mit's Message Board 



Current messages: 9 10-21-97 Open messages: 4 
402 -j 242 246 245 246 

MfXJ b V/ — " — v w » 

*rm 10-16-97 14:32 To:Arlene From-M CCAJIysses 442 -ST 

^-Re: 145 Piccadilly ^1 

.Pis order 3R report on 145 Piccadilly and give copy to Agnes.^420-/ _j_wc/ 

L. j 



406 ♦ 10-17-97 9:24 ToAtit Fronr-Arlene CC: »Ack: 10-17 12:45 
Re: 145 Piccadilly 444 _ 

3R report ordered. Will give copy to Agnes upon receipt. 



■ 10-20-97 10:47 Tortrlene FromiMit CC: 400. 
Re: 233-G Boardwolk ™ 
Call sellers for copy of TDS and Supp. IDS on 233-G Boardwolk.^fl-.^ 

♦ 10-20-97 16:10 To:Mit From:Arlene CC: *A~ck: 10-20 8:42 
Re: boardwalk 

Sellers on Boardwalk w.ill have TDS & Supp ready by too. do you want to 
order smoke detector inspection? „ _ 

4cU—o 



• 10-21-97 8:42 ToArlene FronMit CC: *ACK: 446 
Re: 233-G Boardwalk 

No need. This one's exempt from smoke detection inspection. 



"I 



■ 10-20-97 12:15 To:Agnes FronrMit CC: 464- J 
Re: 145 Piccadilly J 
Order payoffs on 145 Piccadilly. PC0E on Nov. 11th. - 1 - 

466- 

■ 10-20-97 15:10 TojMit FromArlene CC: WD 
Re: 410 Boardwalk #3 

I need copies of Listing Agreement, TDS, Disclosures, etc. on 410 Boardwalk #3 
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Arlene's Message Board 



Current messages: 16 10-21-97 Open messages: 5 



■ 10-16-97 14:32 TotArlene FromMit CC:Ulvsses 4424-v~T 
Re: 145 Piccadilly Anp . /I jent 

Pis order 3R report on 145 Piccadilly and give copy to Agnes f«lr 'l wua 

♦ 10-17-97 9:24 Toirfit FromArlene CC: ♦Ack: 10-17 12:45 T" 
Re: 145 Piccadilly AA4k-^\ 
3R report ordered. Will give copy to Agnes upon receipt. _L 



■ 10-17-97 9:30 ToAgnes FromArlene CC: *Ack: 10-18 8:10 
Re: 145 Piccadilly 

Have ordered 3R report. Will forward to you upon receipt. 

♦ 10-18-97 8:10 ToArlene FromAones CC: «Ack: 10-18 9:45 
Re: 145 Piccadilly "~ . , .. 
Just let me know when you have 3R in hand. I ll cone pick it up. 

■ 10-20-97 10:47 ToArlene FromMit CC: 
Re: 233-G Boardwalk 

Call sellers for copy of TDS and Supp. TDS on 233-G Boardwalk. 462A- 

♦ 10-20-97 16:10 ToMit FromArlene CC: *Ack: 10-20 18:20 
Re: 233-G Boordwolk 

Sellers on Boardwalk will hove TDS k Supp ready by trao. do you want to 
order smoke detector inspection? 

• 10-20-97 18:20 To:Arlene FromMit CC: *Ack: 
Re: 233-G Boardwalk 

No need. This one's exempt from smoke detection inspection. 

■ 10-20-97 14:35 ToArlene FromAJIvsses CC : 
Re: 45 Menlo " 

Change Listing Price on 45 Menlo to $205,000 and update MLS. 

■ 10-20-97 H;47 ToArtene FrppMyssw CC; 
Re: 145 Northwood 

Extend Listing Expiration Date to February 28, 1998 on 145 Northwood. 

■ 10-20-97 15:10 ToMit FromArlene CC: 
Re: 410 Boardwalk #3 

I need copies of Listing Agreement, TDS, Disclosures, etc. on 410 Boardwalk #3. 
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Message Review Screen 



Re: 145 Piccadilly 



>m 10-04-97 11:31 Tortrlene FromMii CC: 1442-* 
Re: 145 Piccadilly— 254 

Where are the signed copies of the TDS and Supp TDS? I need to provide 

copies to the Lender. 1120-1 ^ 

♦ 10-04-97 13:44 ToMit Froi Arlene CC: *Ack 10-04-97 16:14 



1440- 



f 



1444-ST 

Re: 145 Piccadilly ^ 
Buyers' agent will be dropping off signed copies tmo. I will go ahead and give 1 
copies of same to the Lender when I get them ba ck. ^^—142 0-2 

10-04-97 16:14 ToArlene Fron Mit CC: *Ack: 10-5-97 8:43 ...„ ~T 
Re: 145 Piccadilly 7446_v f 
408 Thanks a whole lot! That will save me a lot of time. I owe you one! { 



10-16-97 14:32 To Arlene From Mit CC:Ulysses 

-Re^-145-P-iccadilly iAfin 

Pis order 3R report on 145 Piccadilly and give copy to Agnes. 74W '' 

410 ~^+ 10-17-97 934 ToMit FromArlene CC: *Ack: 10-17 12:45 
Re: 145 Piccadilly 

3R report ordered. Will give copy to Agnes upon receipt. 

■ 10-20-97 12:15 ToAgnes FroaAlit CC: 
Re: 145 Piccadilly 1480-^A 
Order payoffs on 145 Piccadilly. PCOE on Nov. 11th. 

♦ 10-20-97 13:07 Toflit FromAanes CC: «Ack: 10-21 22:10 
Re: 145 Piccadilly 

Payoffs ordered. Should be at title company within 5 bus. days per Lender. 
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Message Rec3 (M003) 230-3 
Message Rec4 (M004) 230-4 

ThreadLevei = 1 

Childld = M006 
— MsgRecOwner = SueG 

SenderName = ArnieS 

Recipient = SueG 
Message Rec5 230-5 

Msgld = M005 

MsgFN = M002.htm 

ThreadLevei = 2 

Threadld = T001 

Parentid = M002 

MsgRecOwner = ArnieS 
SenderName = SueG 

Recipient = ArnieS 
Message Rec6 230-6 

Msgld = M006 

MsgFN = M002.htm 

ThreadLevei = 2 

Threadld = T001 

Parentid = M004 

MsgRecOwner = SueG 

SenderName = Su G 

Recipient = ArnieS 
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Threads Participants Table 148 

_ JTnread_Partieipant-Rec-21 

Participants = P021 
ThreadID = T001 
UserlD = U007 

• • • 

Thread Participant Rec 25 
Participantld = P025 
ThreadID = T001 
UserlD = U01 9 

Thread Participant Rec 32 
UserlD = U027 



Hard Disk 104 ^ 

Msg Files 136 
M001.htm: MsgTxt 
M002.htm: MsgTxt 



Users Table 140 

User Rec 7 

Userld = U007 
Name = ArnieS 
DisplayName = Amie 
HoldAlerts = NO 

User Rec 19 
Userld = U019 
Name = BobB 
DisplayName = Robert 
HoldAlerts = YES 

User Rec 27 
Userld = U027 
Name = SueG 
DisplayName = SueEllen 
HoldAlerts = NO 



FIG. 5B 
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Databases 
tCl08 




150-1 



Sender 
App/Browser 
166-1/168-1 



150-2 



21 



Recipient 
App/Browser 
166-2/168-2 



6.1) Select ACK 

6.2) Send ID of message 
ACKed 



6.3) Update Msg status in DB (close 
thread) 

6.4) Post ACK to recipient IF recipient 
is online 
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702 



*v f\ 

Begin Conference Mode Operations 

f— 



Moderator schedules conference: 
Participants 
Topic 

Date and Time 

Type (Open or Private) 



I 



r 



706 



Server application: 

Adds record to Conferences Table 144, 
Generates unique ID 272, 
Reserves virtual conference room 



W1 0 




714 



Allocate conference room, 
Notify all Participants, 
Allow Moderator to administer 
conference in accordance with Type 



End Conference Mode Operations ) 



716 
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CONFERENCE MODE IMPLEMENTATION 



Mit's Message Board 



Current messages: 43 10-21-97 



Open messages: 25 
•742 

■744 



wm 10-21-97 13:29 To ALL From:Ulvsses CC: f 
Re: OPEN CONFERENCE NOTIFICATION-ROOM 125B-N0W- 
Affects of new Health Ins Benefits: NOW IN PROGRESS. 

\-746 V. 

■ 10-21-97 13:01 To:ALL FromAqnes CC: ^-748 
Re: ANNOUNCEMENT 

Don't Forget about the Picnic tomorrow! See you all there, promptly 9 10AM! 

■ 10-2H7 12:14 ToMit From:Arlene CC: 
•Re: PRIVATE CONFERENCE NOTIFICATION-ROOM 3422-NOW 

Company Policy Review: NOW IN PROGRESS 

■ 10-21-97 00:01 To:ALL From:Dave CC: 
Re: OPEN CONFERENCE NOTIFICATION-ROOM 5557-TODAY 
Improving Cust. Relations: 10-21 0 14:00 

■ 10-20-97 13:01 ToMit FromJdarcia CC: 
-Re: ANNOUNCEMENT 

Surprise Birthday Party for Emily tonight, 8PM at my place. Be prompt! 

■ 10-20-97 9:47 ToMit FromArlene CC: 
*Re: PRIVATE CONFERENCE NOTIFICATION-ROOM 615V-FUTURE 

Company Christmas Party: 10-28 §15:00. y-750 

♦ 10-20-97 1054 ToArlene Fromilit CC: *Ack: 10-20 12:44 
Re: PRIVATE CONFERENCE NOTFICATION-ROOM 6151 
Will Attend. 

■ 10-19-97 12:17 ToAJIysses Fromilit CC: 

•Re: PRIVATE CONFERENCE NOTIFICATION-ROOM 3118-FUTURE 
Long Range Business Plan: 10-29 ©13:00 

♦ 10-20-97 10:34 ToMit FromAJIvsses CC: Ack:10-20 11:17 

Re: PRIVATE CONFERENCE NOTIFICATION-ROOM 3118 
Cannot Attend. 
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CONFERENCE MODE IMPLEMENTATION 



770 



Display Board 



-772 



CONFERENCE SESSION 
ROOM 6151 
10-28-97 



Topic: Company Christmas Party 


Moderator: Arlene 






XYZ Corp, 
Company Christmas Party 
AGENDA 






I. 


Logistics 

A. Setup 

B. Registration 

C. Entertainment 






II. 


Finances 

A. Band vs. DJ. 

B. Dinner Costs 

C. Santa Rental 

D. Gift Exchange 




<7 



PRINT 



HIDE I 



MODIFY 



SEND 1 



Comment Screen' 



-774 



j-776 

Participants 





Arlene 


a 




Agnes 






Mit 






Ulysses 






Sammy 






David 






Alice 






Nicolas 






Isabel 






Larry 




<7 




<? 



Frm Arlene- I think we should ask Larry to play Santa again. 

He did such a good job last year. The kids loved 
him! 



Frrairlit- 



Yes. I agree. Agnes, can you give him a call and 
ask him if he's available on Dec 19th? 



»>Ulysses has joined the session.«< 
FrrAqnes- Okay. Til call him tomorrow. What about caterers? 
Frm: Arlene- Nico did a wonderful job for our Appreciation Party 

last month: I think we should use him again! 
Frn:Ulysses- Hey, everyone. Sorry I'm late. Came from a long meeting 
Frm A! it- Glad you can join us: Uly! We need your input. 
>»Sammy has left the session.«< 

Frm^rlene- Uly, I posted an agenda on the board for everyone 
to see. Wer're on #2 right now. Well, kindo. 



1 1 SEND | [TIITi nNON" 



HOLD 




STORE 




CHANGE 




PRINT 




EXIT 


MESSAGES 




SESSION 




SESSIONS 




MINUTES 




SESSION 
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TALK MODE IMPLEMENTATION 



Z 



800 



To: Mit 



802-i 



TALK SESSION 
Dialogue Input Screen 



] | Directory" 



804- 



V 



I, Mit. Did you hear the rumor about the Christmas Party? 



806- 



Send "1 | Clear | I Cancel 



FIG.8A 
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TALK MODE IMPLEMENTATION 




820 



TALK SESSTION 
Arlene's Dialogue Screen 



f rm:Arlene- Hey, Mit. Did you hear the rumor about 
the Christmas Party? 

■FrraMit- What rumor did you hear? Tell me what 



Ml tell you what I heard! 




Send 



Cancel 



FIG.8B 
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MAIL MODE IMPLEMENTATION 




Folder: Personal/raise 

Mail You've Received: 47 
Dote/Tine Subject 



Mit's Mall Folder 
10-27-97 



eMail Account: mitnaur 



912 



Sender 



Size 



_3 10-27 1:16Pz Toastmoster's Meeting 
906a— Eg 10-29 12S5P 2K 

H 10-27 11:43 A Looking for property to buy tomthui.b9aol.coni 
908a-^r^ io-29 1:16P 6K 



DVoughn9d4tni.org 23K ZD El 
2K C7 B3 



E3 10-27 8:15A New pricing schedule HYoung9onol.com 18K 

'El 10-26 5:36P Company Hiring Policy Review omy_wonq9polko.com 34K 
910a gg 10 _ 26 8:37A 4K 

C3 10-26 3:27P Revise Monthly Stotement WB I l©cnet.cora 18K 

(SI 10-26 3KJ5P 1998 Company Picnic HLoc8webtv.com 22K 

Mail You've Sent: 22 



zd bd 

ZD CD 

ZD QD 

ZD BD 







Date/Time Subject 


To 


Size 








0 


10-27 1:16P News about Moggie 


Ross@fiayinsider.com 


6K 


ZD 


m 




□ 


10-27 12J1P Calendar Orders will be delayed... 


Benas@work4u.com 


IK 


ZD 


m 




0 


10-26 11:19A Mom's Cooking 


minortom9aol.com 


3K 


ZD 


GO 




□ 


10-25 3:09P Cool Web Sites I Found 


Billy6atos9msn.com 


38K 


ZD 


ta 






10-21 12:06P Vacation Plans 


MNublo9kron.com 


12K 


ZD 


m 


a> 


□ 


10-16 7 23 A Operotina Committee Meeting DVauahn9d4tm.org 


22K 


ZD 


QD 




0 


10-16 8:12A Reader's Diaest article about the.. 


. HJHughes9ccnet.com 


5K 


ZD 


BD 




□ 


10-12 1:09P Marketing Presentations 


CFigueroa9webtv.com 


29K 


ZD 


ED 



Move Groups ] | Sort Folder"] | Edit Folder [ | Cancel | 



Check Other Folder Check Other Account 
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